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ABSTRACT 

This report is concerned with the problem of achieving flexibility 
(additivity, modularity) and efficiency (performance, expertise) 
simultaneously in one AI program. It deals with the domain of elementary 
electronic circuit design. The proposed solution is to provide a deduction- 
driven problem solver with built-in control -structure concepts. This problem 
solver and its knowledge base in the application areas of design and 
electronics are described. The program embodying it is being used to explore 
the solution of some modest problems in circuit design. It is concluded that 
shallow reasoning about problem-solver plans is necessary for flexibility, and 
can be implemented with reasonable efficiency. 
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I Introduction 
I. A The Problem 

This thesis reports on the exploration of a classic AI controversy 
regarding the representation and use of knowledge: the trade-off between 
flexibility (or modularity or additivity) on the one hand, and efficiency (or 
expertise or performance) on the other. It focuses on the knowledge required 
for designing elementary electronic circuits. The conclusions I have reached 
are that this kind of flexibility requires all important operations to be 
mediated by explicit rules driven by changes to an associative data base; and 
that the inevitable inefficiency of this organization can be controlled. The 
proposed approach has been tested by implementation of an extensible design 
program cal led DESI. 

The theory of design that I have implemented is based on the idea of 
"functional reasoning." (Freeman and Newel I, 1971) A problem is stated as a 
property which an electronic circuit is to have. The system searches its 
memory for circuits whose known functions fit the requirement. In the 
attempt, it constrains the connectivity and component values of the circuit 
until enough constraints have accumulated to find values which satisfy the 
original property. This simple theory must be complicated in various ways: A 
requirement may not be expressed in a form which triggers suggestions of 
familiar circuits; it may be necessary to transform the requirement until it 
does. More than one device type may be brought to mind in a situation; there 
must be criteria for deciding among them, or ways of synthesizing new circuits 
that perform the functions of all the ones retrieved. A suggested circuit may 
not work out; the theory must specify how plans are changed. 

I require that the embodiment of this theory be "additive"; that is. to 
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the extent possible that new knowledge be expressed by new formulas rather 
than by changes to old. This is partly because of the ease with which such a 
system can absorb new information; and partly because a creative designer 
requires the ability to see the individual parts of its various, often 
conflicting, plans and goals. For this reason, the theory is embodied as a 
"rule-based" system. 

By a "rule-based" system I mean a system which makes progress by pattern- 
driven operations on a data base. There are several paradigms for such 
systems; the classical ones are predicate-calculus theorem provers (Nevins, 
1974a), production systems (Newell, 1973a), and AI languages with pattern- 
directed procedure invocation. (Hewitt, 1972, Bobrow and Raphael, 1974) In 
what follows, I will attempt a synthesis of good features of all of these. 
The result may be described as a system in which plans are assembled piece by 
piece. The rules used resemble predicate-calculus implications. They differ 
in these ways: they may be used to infer what tasks are required or what 
solutions are possible; they are less constrained in the kind of inference 
rule and "self-referential" deduct ions al lowed; they specify how they are to 
be used; and they come in larger, better organized chunks than is traditional 
in predicate-calculus applications. 

Before elaborating further on these requirements, let me bring these 
problems to life with two examples from elementary electronic design, 
illustrating as I go how DESI deals with them. The first example shows how 
choices must often be based on knowledge of current plans. The second example 
illustrates some of the other complexities I mentioned. (These informal 
scenarios are meant to give you a picture of the design problems DESI is meant 
to handle, not the structure of the program or its actual behavior. 1 will go 
over these problems again, once in this chapter to illustrate the 
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representation and use of knowledge by the system, and again in Chapter V to 
shou the performance of the actual implementation.) 

Redescr1b1ng Problems and Choosing Solutions 

Imagine that DESI is given the problem, "Design an amplifier Mith an input 
resistance of 30 kohm and a voltage gain of 5." For now, let us assume this 
problem will be broken into the three subrequirements, "amplifier," "input 
resistance - 30 kohm," and "v-gain - 5." (This must be done with care, since 
these three characteristics are of rather different kinds.) This is only part ■ 
of the problem, for these fragments of the original problem are too precise to 
be suggestive; DESI must further alter the description so that these numbers 
become "range descriptions" like, "high input impedance" and "moderate voltage 
gain." (See Fig. 1.1.) 

"amplifier with input resistance - 30 kohm and 
voltage gain ■ 5" 

\ / 

| | becomes 

I I 
V 

"amplifier" < thing to make 

"input resistance 30k" < high input resistance 

"voltage gain 5" < moderate v-gain 

Figure 1.1 Redescribing a Design Problem 

Once the problem has been described in this form, its fragments trigger 

suggestions of possible solutions. For example, in the context of making an 

amplifier, "high input impedance" should suggest "common^co I lector amplifier," 

and "moderate voltage gain" should suggest "common-emitter amplifier." (Fig. 

1.2.) 
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Figure 1.2 Two Circuits Suggested by Parts of the Problem 
If just one of these had been suggested, the problem would be easy: DESI 
could select a standard schema for the type that came to mind and make sure 

t 

the given numerical constraints could indeed be satisfied. Uhat must it do 
when two or more options occur? In some cases, all but one may be excluded on 
the basis of further considerations beyond the simple problem features that 
suggested the competing options; often, however, what is required is a 
synthesis which combines two suggestions to provide the functions of both. In 
this case, DESI must possess information to the effect that an option 
suggested because of what it does for an amplifier's input resistance may be 
"cascaded" with another option. 

So far, I have drawn these circuits as if they always contained the parts 
shown. However, the notions of "common-collector" and "common-emitter" 
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amplifier each corresponds to a range from general to specialized circuits. 
When - a common-emitter amplifier s1mp11c1ter is desired, the circuit of Fig. 
1.2 is selected almost without thought. But a practiced designer knows that 
the "abstract idea" of this circuit may be realized in other ways. To cascade 
the two circuits of Fig. 1.2, DESI would not just "draw" the same two pictures 
and cram them together in some way. Instead, it chooses more general diagrams 
of these circuits, and reconsiders how they are to be biased and coupled. 
This Mill involve further choices. The result is the circuit of Fig. 1.3. 



bias 
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+15V 



convert current 
to voltage 



bias 
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OUTPORT 



4kQ 




bias & 
coupling 




2knP sets "c 



Figure 1.3 A Cascade of the Two Partial Circuits 

Finally, the numerical constraints set aside in favor of more revealing 

descriptors are taken up again to give the component values shown in the 
figure. 
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Transforming Problem and Solution 

In this second example, I wish to show how much more complicated the 

phases of design can get. Imagine that the problem given is 

Design a network which converts a 1kHz square wave of amplitude IV into a 
sine wave with the same frequency and amplitude. 



1kHz 



2v 



rWJh 




1kHz 




k 

2v 

Y 



Figure 1.4 Signal Conversion Problem 
Even if you know nothing about electronics, it may be worth thinking about 
this problem for a minute before going on. (You don't have to, but the 
problem can be amusing, and illustrates an interesting and common phenomenon 
of problem solving.) 

* * * 
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If you know some elementary mathematics, it probably occurred to you to 
take the Fourier series of each of these signals. In this "frequency domain," 
the problem becomes: 

Desian a network which converts a signal with spectrum 

height =4/n7T 



+ 



U 



1 



M 



Mi l kH 2 



2 3 4 5 6 7 8 9 10 11 12 13 

Figure 1.5 Spectrum of Square Wave 
into a signal with spectrum 



I I I I 



kH: 



1 2 3 4 5 6 7 8 9 10 11 12 13 

Figure 1.6 Spectrum of Sine Uave 

such that the amplitude of the spike at 1kHz is IV. 

If you know some electronics, it might then have occurred to you to try a 
low-pass filter circuit like 
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Figure 1.7 RC Filter 

as your answer, and then try as before to finish the problem off by assigning 

values to the primitive components (here, the capacitor and resistor) which 

satisfy the constraints we have discovered. 

The interesting constraints on this circuit may be stated as follows. 

"Make the amplitude of the output spike at 3 kHz less than 10% of the 
amplitude of the output spike at 1 kHz." 

"Make RC be the reciprocal of the frequency 1 kHz (in r ad/sec)." 

"The ratio of the amplitudes of the outputs at two frequencies depends on 
the amplitudes of the inputs and the selectivity of a device." 

"The selectivity of an RC filter is ..." 
DESI can derive these constraints from the statement of the problem (starting 
with a lot of knowledge about RC filters and frequency-domain operations). 

Unfortunately, these constraints cannot be solved simultaneously. The 
circuit given will make a square wave look "rounder," but the approximation to 
a sine wave will not be good enough. The constraint that deserves the blame 
in this case is that on the selectivity of an RC filter. How can this be 
improved? One way is by "adding a pole" to its system function with this 
circui t: 
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connect to 
old OUTPORT 




New 
OUTPORT 



New system function = old x _L_ 

1 + R'C's 

(Remember to implement A.) 



Figure 1.8 A Circuit for Adding a Pole 
This makes DESTs view of the solution much more promising. (I won't pursue 
this example any further, because the current implementation lacks the 
competence to go any further.) 



Let me list the various types of information that I appealed to in my 
brief overview of how such problems may be solved. First, DESI needs 
knowledge about transforming the problem into a tractable form; this ranges 
from a relatively simple sorting out of multiple requirements, to a more 
difficult transformation from a time-domain to a frequency-domain description 
of a problem. Second, and quite important, there had to be a basis for 
choosing among more than one approach. Third, several constraints had to be 
satisfied in a consistent way. This required knowledge of the physics of 
electronic circuits. Fourth, we had to be able to change plans when our first 
try fai led. 

To make all these kinds of information usable, DESI has to be able to 
reason about its current plans and goals. Transforming a problem may be seen 
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as redescr ibing the topmost goal. Choice of a solution to one problem often 
depends on the other problems under consideration. The calculation of a 
design quantity to satisfy one constraint is pointless unless all the other 
constraints on that quantity are taken into account. And, of course, one 
cannot change plans without knowing what they are. An organization which 
makes using such knowledge practical has been the goal of this research. 

I.B A Rule-Based Problem Solver 

Here is my thesis: problems are solved by reducing them to subproblems. 
Some of these subproblems result in action, others in constraints on action. 
As the solution progresses, the way in which new subproblems are approached 
depends more and more on the state of other subproblem solutions, that is, on 
the requirements derived from the physic9 of the evolving solution and on the 
goal structures that have already been elaborated. It '19 impossible to know, 
as new facts are discovered, what subsequent subproblems will depend on them, 
so all such facts must be stored in the same communal data base and accessed 
whenever they become relevant to a later problem reduction. 

Th'19 is accomplished by implementing DESI as a set of rule9 manipulated by 
a rule-based problem solver called NASL. A rule-based system (Shortliffe, 
1976, Dav'i9 and King, 1975) is one in which knowledge is expressed as 
conceptually small units called rules. 

There are two sources of inefficiency in a system organized this way: the 
overhead paid for storing almost all knowledge in the same associative data 
base, and the nondeterminism inherent in the possibility that more than one 
rule may apply to a problem. The first kind of inefficiency is the price of 
flexibility, but it can be limited by proper organization. One important 
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principle of organization i9 allow rules to come in we 1 1 -organ! zed chunks. In 
DESI; these "packets" of rules (McDermott, 1975) are used to represent circuit 
diagrams, signal descriptions, partial plans for solving problems, and groups 
of rules for making choices. 

The second source of inefficiency, nondeterminism, can be controlled by 
confining it to the information retrieval module. Above this lowest level, 
potential nondeterminism is shut off by applying "choice rules" in ambiguous 
si tuat ions. 

In this section and the next, I will sketch the form and content of DESTs 
rules. This sketch will be filled in in Chapters II, III, and IV. Chapter V 
gives the results that have been obtained by implementing it. 

In any rule-based system, each rule is associated with a pattern by which 
the system accesses it. The system also maintains a data structure, the 
"active processing site," that is intended to describe important aspects of 
the current situation. Rules are matched against this structure, and rules 
whose patterns match are applied in some way. 

The potential advantages of a rule-based system are these: (1) the system 
can see what it is doing because important steps occur at standard times in a 
standard way; (2) the system can keep track of its deductions and/or actions 
in order to explain or undo them; (3) the system can be augmented simply by 
adding new rules. 

Realizing these potential advantages has not been easy. There are three 
classic types of rule-based systems: 

(1) Predicate-Calculus Theorem Provers — Here the rules are axioms and 
the currently active processing site is that rule which is being treated as a 
goal. Applying a rule generates new rules or answers to the problem at hand. 
(Robinson, 1965, Nilsson, 1971, Nevins, 1974a, R. Moore, 1975) 

(2) Production Systems — Here the rules are condition-action pairs, or 
"productions," and the current site is a small list called the "Short-Term 



I Introduction 18 



Memory," or STtl. Applying a rule consists of performing manipulations on the 
STM or doing simple input/output operations. (Rychener, 197G, Newel I, 1973a) 

(3) Artificial Intelligence Programming Languages — These languages may 
be 9a id to be rule based if pattern-directed procedure invocation is taken a9 
rule application and if such procedures are taken as rules. The processing 
site is a flexible record-oriented data base, in particular, the records 
currently being added, deleted, or retrieved. These languages include PLANNER 
(Hewitt, 1972) and its descendants QA4 (Rulifson et. a?., 1972) and Conniver 
(Sussman and NcDermott, 1972). 

(More specific examples will be mentioned for comparison with NASL later.) 

All of these systems have suffered from problems which have kept them from 
realizing their potential. The predicate-calculus systems are the least 
deterministic of the group. The control of application of predicate-calculus 
rules has not itself been rule-directed or directed by much knowledge of any 
kind. However, one of their 9trong points is that the proofs they generate 
play a natural role in keeping track of their actions or justifying them to a 
human user. 

Production systems have very low-level rules. The 9ystem provides simple 
symbol-manipulation ability, but each programmer must provide his own control 
concepts, starting at the level of the subroutine call. This tends to defeat 
real extensibility, since two sets of rules probably have different calling 
conventions. (Production systems have been evolving toward greater richness.) 

AI languages provide more direction and control over problem solving, but 
at the cost of making "rulishness" only a token aspect of procedures. The 
small patterned interface between a program and its callers is usually dwarfed 
by the body of the procedure. Other procedures know that this one is there, 
but they do not know what it is doing. 

A general problem of all these systems is that they are insensitive to 
important aspects of their own operation. Production systems and pattern- 
directed procedures generally do not manipulate themselves. (That is, systems 
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built on them do not encourage or simplify this any more than the LISP 
Interpreter in which they are generally embedded.) 

To remedy these defects, I have implemented the NASL rule-based system to 
depend heavily on explicit representation of control. NASL's active 
processing site is a PLANNER-type data base of rules, but more is stored there 
than in the typical Al-language system. Besides a model of the current 
problem situation, the data base includes a representation of the "current 
plan." Rules are used, not to trigger actions directly, but to add tasks to 
this representation. When the rules are used in a forward-deductive way, they 
resemble productions, with an extra layer of "carefulness" between application 
of the rule and actual execution of the task. (Sussman, 1975) When the rules 
are used in a backward-deductive way, when the interpreter is attempting to 
find a way of carrying out a task, they augment the plan much the way a 
PLANNER- 1 ike language invokes procedures. 

The difference between a plan and a procedure is that a plan may represent 
action at a more abstract level. In particular, the order of steps within and 
between subplans is itself rule-governed. Furthermore, not all tasks 
correspond to subroutine calls to bring something about or calculate 
something. Some tasks are intended to represent "parasitic" actions which 
influence the execution of other tasks, or which require occasional commitment 
of resources. Examples from circuit design are the actions, "Constrain RC to 
be l/2nf, " "Make sure every requirement in the given design problem is 
accounted for," and "Take note of the high-gain requirement in making this 
amp I if ier." 

These secondary tasks, or "policies," are particularly useful in choice 
situations, in which the problem solver tries to decide among more than one 
course of action. The existence of a policy often amounts to the existence of 
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certain rules for suggesting options or deciding among them. 

Another important difference between Al-language procedures and NASL plan9 
is that plans are completely deterministic. All search is done in the rule- 
appliers that try to retrieve, construct or choose among plans. If the 
resulting plan does not work, a "mistake correction" plan must be sought which 
Is appropriate to the kind of mistake that occurred. 

Inability to retrieve a solution plan via the simple deductive retrieval 
mechanism does not cause any kind of "failure." Instead, the system attempts 
to transform, or "rephrase," the problem until it is in a more familiar form. 
This requires that the rules and records of the system be manipulable by 
rephrasing tasks. 

To explain its actions and correct its mistakes, the system must keep 
records of why it did what it did. These are of two kinds: stored chains of 
rule applications, and relations between tasks. The user may ask for an 
explanation of a task in terms of the tasks it was designed to accomplish. 
The system may edit these networks of relations when it runs into trouble. 

I mentioned at the beginning of this section that rule-based systems are 
potentially "extensible," that is, able to accept new information additively, 
without major reorganization, we can distinguish short- from long-range 
extensibility. Over the long range, putting new information in is part of a 
3imple but important kind of learning — "taking advice." It is not the only 
part, because reorganizing descriptive structures and debugging or 
disambiguating what one is told are also crucial. 

Therefore, it is easier to see the importance of extensibility over the 
short range. It is common in AI research these days to assume that knowledge 
is represented in large, we I I -organized chunks (usually called "frames"). 
(Minsky, 1974) Assuming this to be true, we still have the problem of 
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interactions of two simultaneously active chunks. This is just the 
extensibility problem in the small, since each chunk appears to the other to 
contain new information that may be relevant. Unless all frame interactions 
have been foreseen in advance (which is normal in most computer science, but 
not in AI), the information in each chunk must be expressed in terms the other 
can understand. (This is why programs appear to me to be such a poor frame 
representation, since a program is just a large chunk of lines of code, none 
of which means anything outside of its particular context.) At the very 
least, a system must notice potential ly relevant interactions and ask for 
further information when it does. 

In NASL, each rule resembles a Skolemized formula of predicate calculus. 
(Robinson, 1965) (In fact, few substantive restrictions on predicate calculus 
have been preserved in this notation.) The rules are manipulated by a 
PLANNER-like theorem prover. (Cf. R. Moore, 1975) However, the rules can come 
in large chunks called "packets." (tlcDermott, 1975) Packets can include other 
packets (since they are logically just large conjunctions of formulas). One 
use of this is the implementation of hierarchies like those of "semantic 
network" systems. (E.g., Bobrow and Uinograd, 197G) Circuit diagrams, among 
other things, are stored as packets. 

There are several "framish" concepts used in implementing NASL. For 
example, the active tasks of the current plan might correspond to the 
"important questions" terminals of a flinskian frame. (Minsky, 1974) However, I 
have felt free to diverge from the orthodox conventions of frame theory, and 
one must not assume that "plans" or "packets" correspond directly to frames. 



. I Introduction 



22 



r\ J 



I,C Supplying Rule, for Ooolgn 



.e-jlsltjfis svjt-as y«tt.ns9ftg'f.it*}'S '"out Ip cn«" j 36, "isfn^ 



enc ! I s5% fn l **«e i F » iFotsJou !*nlve I »"* i 



ounpMod in tho fero of rutto. The «» jor cyJ? * 



W BO 



IS^IfJ^efn!' !$£ *nrf. 



Jnoo 






tho syotow tat 



<*st) 



WFkfe, 



•e&m^i "toc-c? £ rSj>jS>Jer ;i <- T -- -■ I 



|}«%i f i K*f*?5 »bh6la-i»bnts n£*.*: 



'-• fr-.:~ - : tf 






-,-3.-r 



-«i jisg br-^t, «';oiJ?5--*e'^! in*. -«*?&-*; y *'?*'» 4'noloe, <*3f?en fMim miBUe 6 ,.*8??pf 

v.saofe. tt noriu. oo-lf s«-H5'n : -»«<**•-&»♦ 
.^-.;Uoi53 •^estfcciisj to *?lu*r>o» ajferisoioitg s taitiss^ot *$tn >*»«» t JHAi" nl 

s yd bglsiL-qirtga &■«« esh.n %, : S T k*mii%im'»lrit m- b*v?s-'.«*!q naod.sysrt 
eWoo " r.S;> est mi srst .-tsvswoH t^\8£ ,»to©?1 ,8 A 2) ,-toVo.TCt; «8-sosrW Mm-HBHWiU^ 

'siJosasft* *o 3au=l! s*t ! ea{rtsr.®*w£ir! *s no.HojfioooJqsi ortt *4 sfrtl to ssy 
jr,n« ,e'i«s-ig$.i-t? .Hu;ri-t3 lotfl iteTgonftl fen* MT/&M---.+*Qr1&\ *$mi$%m ■ "n-Knti^n 

i*nj «j bf k>4« 9 -riftn *Hgim rmlii *«x3--rK«> s**J lo e^sst evfts© edf- ,«l<s«s.»o 
I . -,«v3»isH {AS! «usfsrsitt ¥ ,s»sR-it fmi*g«vtta io gf6nl»"»ei 'wwHeswp ^-tsJ^e4^«i'! 



^ 



j 

4 

i 



1 
J 

J 

J 

i 

1 

1 
I 

> 



I Introduction 



23 



Design 
Knowledge 



Electronics 
Knowledge 



Current Data 
Pool 



NASL Rules 




Figure 1.9 Structure of OESI 

The program, loosely known as OESI, has the fol lowing hierarchical 

organization (from the bottom up): 

STP — A PLANNER- 1 ike theorem prover 

EVAL, CHOOSE, REPHRASE — non-3tandard inference mechanisms 

NASL — The interpreter for plans 

DESI (proper) — A set of rules for designing hierarchical systems 

ZORCH — Rules embodying electronics knowledge 

The rules themselves are highly structured. Some of them specify physical 

relations among things like nodes and signals. Higher- 1 eve I rules ars used to 

influence problem choice and transformation. Almost all of them have some 
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procedural component, in that they refer to the current task network. For 
example, even the 9 imp I est statement of Ohm' 9 law, that the current through a 
resistor equals its voltage over its resistance, is stated as a constraint on 
the values of these physical quantities. 

Mo9t of the "raw information" in the system is 9tored in packets defining 
known circuits, such as common-emitter amplifiers, voltage dividers, etc. 
Uhen a circuit of a given type is created, its packet will be instantiated. 
Each such packet contains information of these kinds: 

(1) Component definitions like 

[COMPONENTS ?##VOLTAGE-DIVIDER 

<(R1 ?##VOLTAGE-DIVIDER) (R2 ?##VOLTAGE-OIVIDER)>] 

(NASL formulas are always enclosed in [brackets]. See Appendix 1 for details 
of this and subsequent NASL notation. The prefix "?" indicates a predicate- 
calculus variable; in a packet, "?##X" refers to an object that will be bound 
later to a particular instance of the concept the packet describes. 
(McDermott, 1975). Angle brackets enclose tuples.) 

(2) Connection specifications like 

[NODES ?##VOLTAGE-DIVIDER 

<(T0PN0DE 7/WVOLTAGE-DIVIDER) 
(MIDNODE ?##VOLTAGE-DIVIDER) 
(B0TN00E ?##V01TAGE-DIVIDER)>] 
[NODE- TERMINALS (MIDNODE ?##V0LTAGE-DIV1DER) 
<{»2 (Rl ?##V0LTAGE -DIVIDER)) 
(#1 (R2 ?/WVOLTAGE-DIVIDER))>l 

(3) Constraints and other "frozen tasks" which will be awakened when an 
instance of the packet is created. These are used to associate with a device 
a description of its purposes and further requirements. The commentary 
appearing around the diagrams in Figs. 1.2, 1.7, and 1,8 is represented as a 
set of such tasks. 

These circuits come in hierarchies of various kinds. The components of a 

circuit may themselves be circuits. Circuits may be arranged in classes (such 

as "amplifier") which share properties. One circuit may be derived from 

another by assuming special conditions; for example, the specific and general 

common-emitter circuits I pointed out in Sect. I. A are of this type. All of 
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these hierarchies may be represented by the device of allowing packets to 
include other packets. 

A solution to a design problem is represented as a structure of 
instantiated circuits, with primitive-component values selected. A top-level 
design problem is of the form, "Find a circuit structure with property...." 

It is the information required to go from property to circuit that is of 
most interest. This falls into several classes: (1) knowledge about 
transforming problems, (2) rules for making choices, (3) plans for altering 
and improving circuits, and (4) knowledge about physical constraints on 
quantities. Each of these categories is represented by rules in DESI and 
ZORCH. DESI is a small set of design rules that are intended to be 
independent of any one physical domain; it provides a vocabulary and task 
structure within which ZORCH' s rules can operate. 

For example, OESI provides a standard framework for rephrasing design 
problems. The idea is to transform an unfamiliar design problem into the 
making of a familiar kind of circuit obeying physical constraints, using more 
suggestive hints like "make it linear" or "notice the high gain." (Cf. Sect. 
I. A.) ZORCH provides rules to do this decomposition and then to use the hints 
and constraints to zero in on a diagram. 

The DESI rephrase plan contains tasks to 

"Explode" the given property into "shards." 

Classify shards as to whether they suggest a familiar device type, a 
constraint, or a "design features" like "linearity." 

Gather the suggestions into a new task network. 

In this process, rules like this (from ZORCH) become important: 
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[-/> A (D-5HARD ?+P IX (_?+V) (- (V-GAIN (/?/? _?+V)) _?+G)]) 
(-/> G (/> (OEN ?+G) 50) 

(D-FEATURE ?+P [RANGER V-GAIN HIGH!))] 



This says that a voltage gain greater than 50 should be noticed as "high." 
The symbol "-/>" signifies implication; the letter after it identifies the way 
in which the rule is to be used. (See Chapter II. The "A" means when the 
left side is recorded, record the right; the "G" means call the theorem prover 
to find answers to the left side, and record the right side for each 
substitution returned. The actual rules in Appendices 2 and 3 are more 
indirect and give more information.) 

Once the task network has been transformed, other ZORCH rules come into 
play. These rules are of these kinds; (1) definitions of fundamental wiring 
operations; (2) physical laws I ike Ohm's which constrain numerical quantities; 
(3) plans and pieces of plan for biasing, coupling, and performing other 
standard operations on circuits; (4) rules for choosing among sub-types of 
inclusive circuit categories suggested by the rephrase rules. 

Fundamental wiring operations are defined using the built-in relation 

/tMOD-riANIP (for "model manipulation"). For example, connecting terminals to 

form nodes may be defined by this rule 

[/:M0D-MANIP ?TASK (CONNECT ?T1 ?T2) <> 
<' (EXISTS (N) (AND (DEV-TYPE ?N NODE) 

(NODE-TERMINALS ?N <?T1 ?T2>)) )>K 

This defines an "addlist" (Fikes and Nilsson, 1971) for this action. (Its 

"deletelist" is empty.) 

Physical laws are defined by rules like this; 
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[-/> A (DEV-TYPE ?X RESISTOR) 
(EXISTS (T) 

(/:TASK ?T <> 

(A (CONSTRAIN <* (V ?X) MI ?X) MR ?X)> 

(A (V I R) (- ?V (* ?I ?R)) ))) 
<>) )J 

which commits the designer to the given constraint. CONSTRAIN is a kind of 

policy action defined in DESI; again, DESI provides the vocabulary for ZORCH. 

Choice rules are used for differential diagnosis or synthesis of partial 

solutions. For example, in choosing an amplifier, the rule 

[-/> A (/:0PTI0N ?C ?A1 [/:T0-D0 _?+TASK (MAKE AMPLIFIER) <_?+AMP> 

(MAKE COMMON-COLLECTOR) ] ) 
(-/> A (/:0PTI0N ?C ?A2 

[/: TO-DO _?+TASK (MAKE AMPLIFIER) <_?+AMP> 
(MAKE COMMON-EMITTER)]) 
(/: RULE-TOGETHER <?A1 ?A2> 

[/: TO-DO _?+TASK (MAKE AMPLIFIER) <_?+AMP> 
(MAKE (CASCADE COMMON-COLLECTOR 

COMMON-EMITTER)))))] 

This rule says that a common-collector amplifier and common-emitter amplifier 

may be cascaded to accomplish the purposes of both. (The actual rule comes 

closer to saying this.) The conclusion (/: RULE-TOGETHER. . .] is used by the 

choice protocol of Fig. 1.9. It is used to specify composition of separately 

unsatisfactory choices: /:RULE-IN and /:RULE-0UT are used to narrow the list 

of options. 

Many aspects of the operation of the system cannot be brought out by this 
kind of summary. In the next three chapters, I Mill describe its knowledge 
more systematically. The major omission so far has been a good description of 
the task network and its evolution. Uithout this description, much of the 
content of the rules is lost. 

To compensate, let me sketch DESI's behavior on the second problem I used 
as an example in Sect. I. A, indicating points of interest as I go along. The 
problem is presented as the problem of designing a circuit to convert signals 
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satisfying an input predicate to those satisfying an output predicate. (See 

Chapter IV.) This is written 

[DESIGN 
(X (CKT) 

(CONVERT ?CKT 
(A (IN) 

(AND (PERIODIC (TFUN ?IN) 18.8E-3) 
(FORALL (T) 

(AND (-/> C (/< ?T 0) 

(- ((ONE-PERIOD (TFUN ?IN)) ?T) 
1)) 
(-/> C (NOT (/< ?T 8)) 

(- ((ONE -PERIOD (TFUN ?IN)) ?T) 
-1))) )) ) 
(\ (IN OUT) 

(- (TFUN ?0UT) (* (T) (SIN (* 2888 PI ?T)) )) )) )) 

The input predicate is just a time-domain definition of "1kHz square wave." 

The output predicate defines the time function (TFUN) of the output to be a 

sine wave. (C after "-/>" means: to prove the right-hand side, detach the 

left as a subgoal. ) 

The design problem is used to start a task network or plan. The goal of 

the problem solver is to accompl ish every extant task. In the course of doing 

this, subtasks of various kinds may be generated, which must be gotten rid of. 

In the case at hand, the complicated design problem does not match any 

stored subplan directly. The resulting failure of the theorem prover causes 

the NASL interpreter to set itself the task of "rephrasing" the design task. 
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Figure 1.18 A Rephrasing Subtask 

This rephrasing process notices the conversion problem in the description 
of the desired circuit, and spends some time trying to calculate and compare 
the frequency spectra of the input and output signals. This process results 
in the re-description of the problem as a low-pass filtering problem. (The 
complex details of this example are described in Chapters IV and V.) 

This operation of rephrasing the original problem is carried out by the 
NASL interpreter, operating at a different logical level. In particular, its 
behavior is rule-governed in the same way. The only difference is that 
problems at the louer level become objects of manipulation at the higher 
level. The result of this manipulation ultimately appears as a new problem 
network at the original level. 

The signal descriptions I showed earlier are subject to rules from ZORCH 
which suggest looking at them in the frequency domain (Figs. 1.5 and I.G), and 
looking for a simple transformation between them. The transformation 
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discovered, namely [LOU-PASS 1808], generates the design shards 

• [X (CKT) (DEV-TYPE ?CKT LOU-PASS -FILTER)] 
[X (CKT) (- (LOU-CUTOFF-FREQ ?CKT) 1888)] 

which in turn suggest a basic device type (low-pass filter), constrained to 

reduce its output at all frequencies above 1 kHz to negligible values. 

The task net has now been "elaborated" to the structure of Fig. 1. 11. 



r\ design. 




make a r ^ ^ constrain 

low-pass (J ^U it... 

filter 

Figure I. 11 Rephrased Task Network 
The problem has become "make a low-pass filter, and constrain it to fit the 
exact desired characteristics." The first subproblem in this structure is 
much simpler than the original, and results in the retrieval of a useful plan, 
in the form of a "device schema" for an RC filter. (I will defer the 
possibility of more than one schema being brought to mind until later.) 
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Figure 1.12 Retrieved Circuit and Constraint Task Network 
The problem now (see Fig. 1.12) is to satisfy the constraints given. Some 
of these came with the problem statement, but many more tag along with the 
schema for RC filter (which includes facts about filters in general). A 
useful feature of the NASL language is that we can express the purposes of 
devices in the same language the system uses to express its own: as tasks. To 
use an RC filter is to insist that its resistor and capacitor have values 
compatible with its desired system function. Such tasks are called "Frozen 
policies." 

Such already established tasks are not the only useful kind that ride 
along in device schemata. There are also "expansion obligations" which remain 
to be done. An example of this technique is the definition of "active 
transistor," as a "raw" transistor plus the commitment to bias it in whatever 
context it appears. In the case of the filter, the only expansion obligations 
are to select values for the primitive components. These tasks (see Fig. 
1.12) are carried out by interactions with the new and frozen constraints. 
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(In the current implementation, most algebraic symbol manipulation is carried 
out by the human user.) Values are to be found which satisfy all the 
constraints. Uhen they are found, the fact that they satisfy the constraints 
is to be "protected." (Sussman, 1975) This can be a complex task in itself. 
(Chapter III.) 

As we saw before, there are no values which satisfy all the constraints. 
Even for engineering purposes, an RC filter cannot quite do the job. In this 
case, a failure occurs, which causes the insertion into the network of a 
correction task. This task may have to edit the task network as well as the 
current circuit model in order to solve the design problem adequately. (The 
current implementation stops before this point.) 

I have glossed over the problem of choice in this example. It is more 

obviously relevant in the case of the first example of Sect. I. A, designing a 

buffered amplifier. In this case, rephrasing is relatively simple, being a 

matter of unpacking a lambda expression such as 

l\ (X) (AND (DEV-TYPE ?X AMPLIFIER) 
(- (V-GAIN ?X) 5) 
(- (INPUT-R ?X) 38880))]. 

However, these fragments suggest more than one kind of amplifier, as we saw. 

(Fig. 1.2) In other words, the system has converted a problem with no 

apparent solutions into a problem with tuo apparent solutions. This 

embarrassment of riches is handled by invoking the choice mechanism, a simple 

"protocol" for calling the theorem prover. In this mode, a series of staccato 

deductions are made which attempt to rule out alternatives, vote in favor of 

alternatives, or synthesize new ones. (See Chapter 2.) The relevant rule is 

the one that says, "if you are trying to choose among different ways of making 

an amplifier, and option 1 was suggested because of its input resistance, and 

option 2 for some other reason, replace these options with (CASCADE | opt ion 1| 
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loption 2|]." (A simplified version of this rule appears above.) 

Other choices that occur in these examples are handled similarly. There 
is a rule that the general common-emitter circuit is the starting point for 
implementing a common-emitter coupled to something else. In the second 
example problem, if the system is ever told about LC filters, we Mill also 
have to give it rules like 

"Use an LC filter if the power involved is high." 

"Other things equal, don't use an inductor circuit if you can help it." 

For DESPs actual behavior on these problems, see Chapter V. 

1.0 Relation to Previous work 
1.0.1 Problem Solving and Reasoning 

The problems I am attacking in this research are not new. The problems of 
generality vs. expertise were originally studied by Allen Newell and his 
coworkers around 1968. (Newell, 19G2) Their efforts produced a "General 
Problem Solver" which we have been trying to debug ever since. (Ernst and 
Newell, 1969) GPS was a "means-ends analysis" problem solver which applied 
state transformation operators to bring it to its goal. McCarthy (1959) gave 
us the term "advice taker" to describe a program which can take new 
information and use it to do better. The creation of such a program is still 
my long-term goal and, in a sense, that of most other researchers. 

Uhile this research was in progress, a tide of "rule-based" AI programs 
has risen which NASL seems to be a part of. Its ancestors are the systems I 
described in Sect. I.B. More recent, special -purpose rule-based systems have 
sought to overcome their limitations. Shortliffe's (1976) MYCIN is a limited 
but elegant medical-diagnosis system which uses a backward-chaining deductive 



I Introduction 34 



system. Sussman and Stallman's (1975) EL does electronic circuit analysis by 
forward deduction. Both of these systems keep a record of deductions. EL 
uses these records to rethink deductions based on unworkable assumptions. 
(Stallman and Sussman, 1976) Both systems use them to explain their deductions 
to a human user. 

The NASL system differs from these in that its control language is aimed 
at a higher level of abstraction. Its rules, expressed in a predicate 
calculus, specify conclusions rather than actions. Action is achieved by 
having certain conclusions be interpreted as "required tasks" by the action 
interpreter. The notion of "task" is intended to be very inclusive. 

HYCIN and NASL can both be given new rules, which, if they are not buggy, 
interact with the rest of the system in efficient ways. However, MYCIN* 9 rule 
language is deliberately restricted to the domain of fault diagnosis in poorly 
understood systems. (Davis et. a7., 1975) (MYCIN is superior to NASL in 
having a more developed procedure for graceful assimilation of new rule9. 
(Davis, 1976)) EL's rules have stylized LISP code bodies. They can do 
anything, in principle, but the system functions most elegantly when organized 
around the satisfaction of numerical constraints. MYCIN does almost entirely 
backward chaining during deduction; EL, forward chaining. 

The most important conceptual problem I have found in working on NASL is 
the requirement that the control structures of a problem solver ought to be 
simple enough to be inspectable, but contain enough higher-level concepts to 
be useful when inspected. The MYCIN group express this as a demand for 
"stylized programming" (Davis et. al., 1975). They have achieved impressive 
results in two areas. First, by use of "meta-rules, " their diagnostic program 
can guide its oun flow of control. This is something like my "choice 
protocol" in which NASL uses choice rules to decide how to proceed. Second, 
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their knowledge-acquisition program knows enough about the "sty I izat ion" to 
participate in writing and debugging new rules. I shall make a more detailed 
comparison of these two capabilities with actual and potential abilities of my 
program in Chapter VI. 

The main limitation of MYCIN'S style of rule-based programming is that it 
is wholly oriented toward making tests and letting them "cast votes" for a 
result. There is no concept of planning or even acting. Davis et. al . 
(1975) acknowledge that for a domain with a more precise theory than medical 
diagnosis, a different control structure is called for. I hope DESI is an 
example. 

Stallman and Sussman'3 (1976) EL is implemented using a language called 
ARSE which is embedded in LISP. The primitives in ARSE implement a system of 
forward deduction and "guessing," aimed toward finding a consistent assignment 
of variable values in a constraint network. ARSE has been used experimentally 
on other tasks involving constraints (Mason, 197G, Doyle, 197G) , and so has 
modest pretensions to generality. ARSE's control structure is formally close 
to NASL's (and helped inspire it). ARSE maintains "demon queues" generated by 
ongoing deductions. However, EL lacks the need or power to inspect these 
queues efficiently. NASL embeds the control structures in an associative data 
base, and generalizes the notion of queue to a task network. 

In this respect, the closest control structure to NASL is Sacerdoti's 
(1975) NOAH. This is a brilliant program for planning a mechanical assembly 
and advising a person carrying it out. The planning part constructs a 
hierarchical network of ever more detailed plans. These plans are not 
programs; in particular, they do not have to be totally ordered. As parts of 
the plan are expanded, their interactions with each other are noted and 
corrected for by enforcing orderings. 
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The main difference between this part of NOAH and NASL is that- NOAH is a 
plan compiler, while NASL is an interpreter; that is, it expands and executes 
pieces of plan as it goes. This is necessary because NOAH has a simple 
STRIPS-like (Fikes and Nilsson, 1971) assumption about actions which NASL 
doesn't share. In particular, NASL is not as sanguine as NOAH about expanding 
a future action, because it has a limited model of the world at that point. 
It does not attempt to summarize the effects of all tasks as state changes, so 
it cannot have a domain- independent algorithm for checking interactions 
between steps. In particular, actions like "Design..." and "Constrain...," 
whose effects depend on how they are carried out and/or what else is being 
executed, do not fit into Sacerdoti's framework. This makes room for more 
sophisticated knowledge about action, but it is a pity that I cannot use 
Sacerdoti's simple and (within their limits) powerful algorithms. 

I have also profited from reading papers by Nilsson (1973) and Philip 
Hayes (1975) on interleaving planning and execution. Several researchers 
(Schank and Abe I son, 1975. Abe I son, 1975, Rieger, 197G, Charniak. 1975) have 
done research on classification of plans analogous to my taxonomies of Chapter 
II. Usually, however, they have been more concerned with analyzing narratives 
than with actually solving problems, which has led to different criteria for 
classification. Perhaps some synthesis of these approaches will be possible. 

A class of systems with which NASL shares certain properties are the 
"utility" AI systems which have appeared recently. These are systems which 
provide data and control representations for users, who are expected to use 
these facilities for problem-specific programs. Examples are the AI languages 
(Bobrow and Raphael, 1973), Bobrow and Uinograd's (197B) "Knowledge 
Representation Language," and Srinivasan's (197Ga,b) "heta Description 
System." The AI languages provide assertion-based data bases like NASL' 3. 
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(NASL and STP are descended in this direction from the AI language Conniver. 

(Sussman and McDermott. 1972)) The other two systems are more semantic-network 
oriented. (Hoods, 1975) This is in many ways merely a formal difference. 
Other differences between these research efforts depend on healthy differences 
of focus. For example, the KRL group is more concerned with recognition 
problems than I have been. 

A bigger philosophical difference is that NASL is an attempt to provide a 
plan description language rather than a programming language. The distinction 
may be wholly metaphysical; however. I believe that several features of NASL 
plane, especially the notion of "policy," if implemented properly, belong to 
plan description rather than programming. A concrete distinction between NASL 
and the traditional "AI utility" (Hewitt, 1972) is that NASL, far from 
requiring a program to specify a piece of knowledge, requires a body of 
knowledge to specify a program. I believe that Srinivasan's MDS results from 
a similar orientation, but he is more concerned with general puzzle solving 
than capturing the knowledge in a rich domain. 

In any case, the older, less pretentious AI languages are the only members 
of this list of systems (NASL included) which are mature enough for their 
flaws and strengths to be visible. Which features of the newer systems will 
endure remains to be seen. 

Unlike most of the problem solvers mentioned, NASL uses a theorem prover 
to do sophisticated deductive information retrieval. This use of theorem 
provers has been suggested by many people. (Travis et. a7., 1972, Darlington, 
19G9, Moore, 1975) My theorem prover, STP, resembles most closely that of 
Nevins (1974a). with features from the work of Bledsoe (1975) and Ernst (1971, 
1973). Those familiar with the theorem-proving literature will enjoy Appendix 
4, which describes its features. 
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Other people have studied somewhat different uses of theorem provers in 
problem solving. (E.g., Fikes and Nilsson, 1971) In the past couple of year3, 
one group of people has been urging the use of a predicate-calculus theorem 
prover as the only interpreter of a problem solver. (Koualski, 1973, 1974, 
Uarren, 1974, Hayes, 1973b, Tarnlund, 1975) I think this view is misguided. 
Generally one does not go very far with this approach before he starts adding 
corruptive features, such as ordering the axioms, putting in dummy predicates 
to control search, allowing rules to refer to formulas, etc. (Uarren, 1974) 
fly conclusion was that it is better to admit defeat from the start, so I put 
control features in as concepts manipulable by the calculus and defined by the 
interpreter, and tried to preserve some of the purity of the theorem prover 
t tsel f . I 9hall have more to say about the success of thi9 attempt in the 
conclusion. 

1 should mention that the concepts of action and decision have concerned 
philosophers fqr hundreds of years. Recently, a whole branch of analytic 
philosophy has sprung up around them. (Langford, 1971, Brand, 1970, Danto, 
19G5, Goldman, 1978) Many of the workers in this field have interesting 
things to say about the logic of action. For example, the computer 
scientist's notion of a "primitive" is reflected (somewhat dimly) in 
statements like, "••• those actions, ... performed by M, which he cannot be 
said to have caused to happen ... I shall designate as basic actions." (Danto, 
19G5) Unfortunately, these philosophers are much too reluctant to imagine 
that the mind behaves like a device with a real structure; all of their 
definitions are in terms of phenomeno logical rather than technological 
categories. For example, Goldman (1970) gives the following exegesis of the 
notion of "basic action": A basic act is an act fi such that "if S wanted to 
exemplify ft (at t) , he would exemplify A (at t)." He then must spend no 
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little effort explaining away paralytics. I think that in the long run 
philosopher exposed to AI ideas are most likely to arrive at useful concepts 

in this field by explaining "want" and "act" in terms of hypothesized internal 
constructs. 

I.D.2 Electronics and Design 

The usual problem domain for a researcher with my pretensions is some 
class of puzzles (Ernst and Newell, 1969) or "narrative understanding." 
(flcOermott, 1974a, Charniak, 1972). I have chosen elementary electronic 
circuit design instead, for these reasons: 

(1) It is not as broad and sloppy a domain as "story understanding." One 
can reach critical mass" with a data base much faster. There are clearer 
cr.tena for success. Electronics involves, I hope, as few mental competences 
as possible in an interesting domain. 

(2) On the other hand, there is room for a variety of kinds of knowledge. 
Ihe doma.n cannot be, and doesn't have to be, represented fully by a state 
space and a set of operators. Puzzles are both too easy and too hard at once; 
they are probably a misleading example of problems that succumb to human 
thinking. 

(3) The subject matter is already formalized to some degree, so that I can 
focus on formalizing the control knowledge that is necessary. 

(4) Electronics is simpler than other engineering domains in that it 
requires less knowledge of space, time, and motion. Expertise in these areas 
presumably draws on innate abilities we have difficulty bringing to light. 

(5) My research has had the benefit of being part of an ongoing fllT AI 
laboratory project in automating electronics reasoning. Concepts used by 
Sussman and Stal Iman (1975), Stallman and Sussman (1976) . and A. Brown (1975) 
have been taken over, sometimes with some modification, into DESI's knowledge* 
base. (This .s especially true of the parts concerned with signal description 
and electronic analysis.) 

(G) fly wretchedness as an electrical engineer should make it easy to 
construct a program as good as its creator. 

The main drawbacks to electronics are 

<1) It is somewhat inaccessible to the average AI researcher or 
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psychologist. People lose interest in documents regarding something they know 
little about. (Who knows what DENDRAL (Buchanan et. a7., 19G9) really does?) 
I- have tried to keep large sections of this text independent of electronics. 
Only Chapter IV and Appendix 3 rely on it. 

(2) Electronics knouledge as presented in introductory texts leans on 
spatial representations to some degree, even if not as much as other branches 
of engineering. Frequency-domain manipulations and pole-zero plots are 
examples of this. I have tried to preserve the structure of this knowledge in 
formal expressions (see Chapter IV), but I am aware that humans probably use 
more "uired-in" modes of spatial reasoning, whatever that may turn out to 
mean. I doubt that one could choose a better domain than electronics for 
avoiding this problem, however. 

My knowledge of electronics is mainly derived from books. (Senturia and 
Wedlock, 1975, Hayt and Neudeck, 197G, Watson, 1970) This is reflected in the 
fact that the problems DESI has been exposed to are "problem set" problems. 
not the sort that a technician would encounter in daily practice. 

There is a large literature on the theory of design, artificial 

intelligence and design, and "computer-aided design." So far, however, the 

intersection of these fields is almost empty. Books about the design process 

(Alexander, 1964, Asimow, 19G2, Buhl, 19G2, Glegg, 1973) consist mainly of 

advice for avoiding overlooking things in pondering problems and working out 

solutions. About proposing solutions to start with, most of these authors say 

things I ike this; 

"What enables us to draw from the warehouse of our experience just the 
right set of elements, and to put them into just the right combination so 
that they have a sense of fitting the situation, we do not know, since no 
definite solution exists." (Asimow, 19G2, p. 45.) 

This author is certainly correct that we do not know; programs like DESI are 

only tiny steps toward a theory of creativity. Of course, as a working 

hypothesis, we take issue with the claim that no solution exists. 

Design has attracted artificial-intelligence researchers, particularly at 

Carnegie-Mel Ion University, for some time. Broadly speaking, areas like 

automatic programming, and, indeed, all problem solving, fall under the 
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heading of "design." HoHever, the theory of design narrowly construed has 
been- explored by workers like Grason (1970), who studied resolution of 
constraints on floor plans; Eastman (1968) , who did a formal pychological 
study of performance on the task of redesigning a bathroom; Haney (1368) , who 
studied the automatic design of computer instruction sets; and Latombe (1976) , 
whose rule-based design system is an interesting alternative to mine. I have 
found especially useful the theory paper by Freeman and Newell (1969) on a 
general theory of design, from which I have borrowed heavily. (See Chapter 
III.) 

One might expect the field of "computer-aided design" (CAD) (Vlietstra and 
Uielinga, 1973, Kuo and Magnuson, 1969, Furman, 1978, Rosenbrock, 1974) to 
have produced many expert programs for a general AI program to compete with. 
This is not yet the case; "CAD" usually has little to do with the automation 
of the actual design process, but concerns itself with graphics packages, 
analysis programs, and other interactive aids to it. For example, one author 
distinguishes "three modes of (computer] operation: 

(i) Analysis. An engineering situation is specified in full 
mathematical detail by the designer, and the computer draws certain 
further mathematical consequences.... 

(ii) Synthesis. The designer specifies in detail the properties which 
his system must have, to the point where there is only one possible 
solution. The computer finds this solution. An example is optimal 
control. 

(iii) Design. This is the creative act of a designer, guided by 
calculations on the computer and interacting with them in a sequential 
manner to produce a satisfactory solution." (Rosenbrock, 1974, p. 29) 

The electronics synthesis tasks to which computers have been put include very 

low-level operations such as printed-circui t layout (e.g. .Fletcher, 1974) and 

filter design (e.g., Chohan and Fidler, 1974). The approaches taken by most 

people in this field are usually very "mathematical," and concentrate on 

techniques for discrete or continuous optimization. For example, one approach 
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to circuit design in the literature (Director, 1974) consists of putting in. as 
many components as one deems plausible and letting the program find the 
optimal component values for the task given. Many of these components will 
assume null values and "vanish"; thus this approach starts with a big circuit 
and finds the subset that does the job! 

CAD is only beginning to become aware of non-numerical techniques. (But 
see Powers, 1973.) DESI relies almost entirely on non-numerical techniques, 
and is very poor at constraint resolution and component-value optimization. A 
practical system would have to combine the tuo approaches. 

It is impossible to survey this field in detail here. It includes its own 
journal, Computer Aided Design, and supports periodic conferences. 
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II Expressing Knowledge 1n NASL 

The heart of DESI is the NASL interpreter, and the STP theorem prover 
which it drives. The theorem prover gives the system a general and flexible 
notation; the interpreter imposes an innate interpretation on some of the 
expressions of this notation. In this Chapter, I gill give a discursive 
introduction and overview of the interpreter, describing STP and other 
inferential protocols as they come up. (See Fig. 1. 9.) 

The NASL interpreter is a problem solver of the "problem reduction" type. 
(Nilsson, 1971) That is, it solves problems by reducing them to simpler 
subproblems. The differences between this structure and a programming 
language are: that a problem solver must decide upon the order in which to 
attack subproblems; that a problem solver often has subproblems of the form 
"reduce problem so-and-so," where a programming language has only the 
subroutine call, and that a problem solver must occasionally choose between 
alternative approaches. 

The designer of a problem solver must confront the problem of search. For 
problem-reduction problem solvers, this classically takes the form of a search 
through an AND/OR graph of possible approaches. (Nilsson, 1971, Fahlman, 1973, 
McDermott, 1974a) Uhether the search strategy is depth-first or more clever, 
it depends upon being able to save and restore states of the problem solution 
and hence of the "world model"; • this has recently tended to be implemented 
using a "context" mechanism. (Sussman and McDermott, 1972) 

I believe that searching will always be a part of Artificial Intelligence 
technique. However, it seems to me that search among alternative sequences of 
subproblems and world models is a mistake. My principal reason for this 
belief is the observation that in the normal course of human problem solving, 



II Expressing Know I edge in NASL 44 



a rather different faculty is used more heavily, namely, the ability to 
correct one's errors. The difference between these alternatives is thiss if a 
"state of the world" is thought of as an internal data structure, completely 
known and under control, it is just as easy or easier to return to an earlier 
state to try something else as it is to generate a new one. But if states of 
the world are really states of the whole world, about which one's information 
is limited and his control slight, quite the opposite is the case. 

So the question, for electronic circuit design, is whether the unfolding 
circuit model is to be thought of as an internal data structure or as a 
diagram on a piece of paper. A little reflection on this choice has drawn me 
to the second alternative. Since useful plans will ultimately have to be 
applied to the real world, whose surprises will always cause mistakes and 
revision, the problem of correcting errors rather than "popping them off the 
context tree" will have to be faced eventually. There is no point in 
perfecting a plan down to the last detail if circumstances will wreck it. 
This is probably why people worry so little about producing optimal plans. 

If search isn't through states of the world model, but it is necessary, 

what is it that is searched? I think it is knowledge about courses of action. 

People can correct states of the world created by the wrong plan, but they 

don't normally do this as a way of stumbling on the right plan. Instead, they 

use know I edge I i ke 

"Under circumstances ..,, plan ... will work." 
"If .... don't do " 

Consider the difference between human and machine playing of chess. I 

will assume the reader is familiar with the usual program organization around 

the idea of minimax tree search. (Slagle, 1971) A human, by contrast, learns 

to play. His initial plan is simply to make a legal move, wait for his 
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opponent's reply, and repeat this until the opponent wins. As time goes by, 
and he sees and hears more and more about the game, where does he put what he 
learns? According to the theory I am presenting, it becomes part of the 
advice surrounding the "make a move" step. This advice is usually in terms of 
board patterns, phases of the game, etc. Eventually, more sophisticated 
advice in terms of anticipating possible opponent replies is assimilated. If 
the deductive system for manipulating this advice is adequate, simple tree 
searches will appear as a trace of its manipulations. But this will never be 
assimilated to the overall planning level. The planning level does not become 
nondeterministic. Instead, what begin to appear there as the player becomes 
more confident of his powers are "game plans," long-term strategies uhich 
influence hi 9 choice of moves. 

This sort of search through knowledge about alternative courses of action 
is uorth spending a lot of effort on. It has three loci in the NASL system. 
The principal one is the theorem prover STP. (Sect. II. B. 2) This is 
supplemented by "choice Information." (Sect. I I.C.I) If all else fails, the 
system calls itself recursively to "rephrase" an action. (Sect. II.C.2) I 
have worked hard to make these devices sophisticated. I have given less 
thought to the problem of undoing mistakes (Sect II. E), and none to the 
question of learning search knowledge. 

Because deductions about courses of action are so central to the theory, 
NASL mu9t be a language for describing problems, plans, and physics. The 
categories it uses for descriptions, and the inference algorithm it can call 
upon to manipulate them, determine its abilities and limitations. The 
limitations are in some ways as important as the abilities. The fewer ways 
there are to express something, the more likely it is that the formulas 
related to it will be noticed during rule application, and the more flexible 
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and extensible the system will be. Conversely, to the degree that each user 
is forced to make up his own control conventions, the less likely it will be 
that information from one user wi 1 1 ever affect the system' 3 approach to 
problems posed by another. 

NASL Is not a typical programming language, since the user can intermix 
fragments of plans and axioms governing the physics of problem domains with 
fully developed programs. On the other hand, it bears a stronger family 
resemblance to programming languages than to anything else, so I have included 
a "programmer's guide" at the end of this chapter for those interested . in 
programming in NASL. 

1 1. A The Natural History of Actions 

The fundamental concept implemented by the NASL interpreter is the concept 

of task. A task is an activity to which the interpreter is committed. The 

basic drive of the interpreter is to accomplish all the pending tasks. 

Examples of tasks from several domains are, 

"Put Block A on Block B." 

"Wait here for five minutes." 

"Put the male chicks in this box, the females in that one." 

"Uin the war, and keep the peasants happy." 

"Think of a fallible Irishman." 

"Keep your promises." 

"Convince yourself that all equilateral triangles are isosceles." 

In electronic design, tasks range from wiring two objects together, to 

designing a hi-fi system, to finding a resistance that satisfies a constraint. 

The reason for the broad definition is my goal that as much as possible of 

what the interpreter is doing should be explicit, so that reasoning about it 

can be shallow. For the same reason, it will be important that control 

information be expressed in a notation compatible with everything else. So I 
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represent tasks as NASL formulas of the form 

. t/:TASK | name | < -input pvars- > 

(A ( -vars- ) | act ion | ) 
< -output pvars- >] 

Unfortunately, I must pause here to describe the notation, both object and 
meta. NASL formulas are always enclosed by [brackets!. Uhen I am describing 
a formula, I enclose syntactic variables in brackets like this: " | . . . | " or 
like this: "-...-". The second kind indicates that a sequence of syntactic 
constructs is wanted. So, for example, an instance of a task might be of the 
form 

t/:TASK (COUPLER PLAN071) <* (BUFFER//72) MAMP#73)> 

(X (STAGE1 STAGE2) (COUPLE 7STAGE2 7STAGE1) ) 
<'(CKT#74)>] 

This describes a task, named [COUPLER PLAW71J, which requires taking the two 
circuits UAHP073)] and [ (BUFFER//72)] and COUPLing them to make something 
which will be called [(CKT#74)J. (Notice that the NASL notation permits 
tuples of objects delimited by <angle brackets>, and X-expressions to express 
functions and predicates.) /:TASK is a predicate of four arguments. It 
begins with the prefix "/," which indicates that it is a built-in predicate 
used by the interpreter in some way. A complete catalogue of built-in 
predicates and functions appears in Appendix 1. 

The word "pvars," for "plan variables." refers to terms, such as 
[ (BUFFER072) 3 and [(CKT074)], uhich are set equal to calculated quantities in 
the course of executing tasks. They acquire values by appearing in "rewrite 
rules" of the form 

[-/> *|term| |value|] 
(Cf. (Bledsoe and Tyson, 1375), where they are called "reduction rules.") In 
my example, if [-/> • (BUFFER#72) DEW75J and [-/> • (AMP073) DEV#761 appear in 
the data base before execution of the task [COUPLER PLAM71J, DEY#7G and 
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DEV#75 might be coupled to produce DEV//77; then the interpreter would add (-/> 
' (CKT074) DEV077J to the data base. (For an explanation of the single quotes, 
see Appendix 1 or Sect. II. B. 2.) In defining actions like COUPLE, 1 will 
indicate their outputs with the symbol "-■>" thus: 

[COUPLE |ckt 1| |ckt 2|] «> <|new ckt|> 
to show what new value formulas they leave in the data base. 

Anyone familiar with the AI languages (Bobrow and Raphael, 1974, Hewitt, 
1972) will recognize the concept of "present in the data base." In NASL, 
there is always a current "data pool" for formulas to reside in. Formulas 
found there are supposed to be true; those absent have unknoun truth values. 
(See Sect. II.B. The phrase "data pool" is meant to supersede the misleading 
word "context." (McDermott and Sussman, 1973, Rulifson et. al., 1972)) 

This notion of task already embodies a complexity not found in the action 
languages of Sacerdoti (1975) and others (Sussman, 1975), namely, that tasks 
will not be fully specified until their input pvars are known, and that tasks 
can compute values to be used by subsequent actions. It will be seen that 
this broadens the scope of the action system considerably, while making future 
actions harder to analyze. It seems essential for automating design. 

Uith just this much machinery, plus a- simple forward deduction scheme, we 

have a notation similar to that of a production system (Newell, 1973a, 

Rychener, 197G) . For example, we might have a deductive rule that says 

((DEV-TYPE ?A COMMON-EMITTER) 
d 3B(/:TASK ?B <> (X (BIAS ?A)) <>)]. 

meaning, "Every common-emitter amplifier must be biased." (I have introduced 

standard logical notation for implication and quantifiers. (Suppes, 1957) 

Variables are prefixed by "?"; free variables are supposed to be universally 

quantified. The internal notation for implication will be explained below.) 
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This rule is analogous to a production in having a condition on the left and 
an action on the right, but it differs in certain crucial ways. 

First, we are not limited to condition-action pairs. The more basic case 
is "condition-condition." This enables us to treat deductive information 
retrieval as a process distinguishable from plan execution. It can be 
optimized separately, using techniques specific to the kind of search that 
arises during deduction. (Moore, 1975, Fahlman, 1975b) More important, since 
the system knous uhen it is doing deduction, and when action, it can keep more 
revealing records for use in choosing courses of action, explaining what it 
did, and recovery from errors. (In the future, such records could be used for 
careful assimi lat ion of new, possibly unrel iable, information. Cf. (Davis, 
197G, McDermott, B974a) . By contrast, since the meaning of a condition-action 
pair depends entirely on the meanings (some deductive, some not) given to 
symbols by the behavior of the rest of the system as a whole, it is impossible 
to say whether a new rule of this kind is "correct" without extra commentary.) 

Second, deducing /sTASKS before executing them gives an extra layer of 
"carefulness" to the system. (Cf. (Sussman, 1975), where the term "careful 
mode" is introduced.) A task is always noted in the current data pool before 
being executed. Here it can trigger other tasks or be available for other 
deductions. Furthermore, the system can note a task some time in advance of 
when it actual ly decides to do it. For example, a task can appear before its 
pvars' values are known. More generally, a formula of the form 

[/: SUCCESSOR | task name 1| |task name 2|] 
must mean that task 2 is to be postponed until task 1 has been "begun" (in a 
sense explained below). In this way, a network of tasks linked by /jSUCCESSOR 
relations and variable flows is created (which the interpreter will munch 
"from left to right"; cf. Fig. II. 1). 
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Figure II.l A Task Net, or "Plan" 
Finally, a typical production-system action is always a primitive that can 
be carried out immediately, while some NASL tasks require must be broken down 
into subtasks in order to be executed. This requirement is what makes NASL a 
problem solver. In other word9, a ta9k can be a9 much a part of the problem 
as of the solution: it looks like part of the solution to its superiors, and 
part 'of the problem to its subtasks. 
» Thus, a task (or action) is either primitive or problematic. An action 
may be primitive in two ways. It can have a LISP program for carrying it out, 
or it can have a set of raode7 manipulation statements that hold true of it. 
These statements are the same as STRIPS' s add- and delete-! ists. (Fikes and 
.Nilsson, 1971) They are sufficient to represent completely only the simplest 
of actions, but they make these actions easy to reason about. (Cf. Sacerdoti, 
1975). 

A problematic task must be "reduced" to one or more subtasks. This 
relation between tasks is expressed by formulas of the following sort: 

t/:SUBTASK |subtask name| |supertask name|l 
A task can be the subtask of more than one super task. 
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Task reduction can occur in more than one way. The deductive system can 
infer a complete set of subtasks of a task in the course of forward deduction. 
However, this fails to give enough direction or power to the problem-reduction 
process. As described in Section II. B, the interpreter must have the concept 
of one action being a way of carrying out another, expressed like this: 

t/:T0-D0 | task name| |action| < -output pvars- > |method|J. 
This is intended to mean that the method is an effective, feasible, and 
permitted way of accomplishing the task consisting of the action. Such 
statements can be used in the creation of subtask3. 

The "method" to which a task is reduced may consist of a single action, or 
it may be a "macro action" which stands for an entire subnet of new tasks. 
This requires the notion of a plan schema, an abstract object. Instances of 
which may be thought of as hanging as little subnets off nodes in the task 
network. (Fig. 1 1. 2) The manipulation of instances of these schemata is 
described in Sect. II. B. 1.2.1. 
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Figure 1 1. 2 Task Network with Subnets 
Thu9 tasks may be classified according to whether their actions are 
primitive or problematic. These classifications form one of the taxonomies 
shown in Fig. 1 1. 3. 
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Figure II. 3 Logical Taxonomies of Tasks 
The other two taxonomic classifications are independent of this one. One 
classifies tasks according to "monasticism. " Every task is either 
Inferential, in which case it consists of inferring formulas from other 
formulas supposed to be true; or "worldly," when it or some of its subtask3 
perform model manipulations. This classification is expressed by means of the 
predicate /: INFERENTIAL. 

The last taxonomy is the important classification by "parasitism." A task 
is either primary, meaning that it has steps to be pursued in order; or 
secondary, meaning that its "execution" amounts to influencing or monitoring 
the execution of primary tasks. Ongoing secondary tasks are somewhat 
grandiosely called "policies." How they are handled is described in Sect. 
II.B. Some representative classes of policies, expressed in English, are 

"Uai t unti I ... is true." 
"Notice if formula ... is removed." 

"Take into account desired feature ... of the device you are 
designing." 

"Constrain quantities ... to satisfy ..." 
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Policies, like primary tasks, may be primitive or problematic, worldly or 
inferential. 

A policy may have a scope, Mhich is the primary task whose execution (or 
whose subtasks' execution) it is intended to influence. As you might expect, 
this is indicated thus: 

(/:SC0PE (secondary task name| Iprimary task name|) 
Policies do not outlive their scopes. In drawing task networks, I will put a 
little cloud around a task to indicate that it is the scope of one or more 
policies; the policies will be tied to these cloud9 with a line. (Cf. Figs. 
III. 7 and I II. 8.) 

There is no mystery to the notion of policy. All computer programs embody 
policies; the particular data-base and interrupt mechanisms I use to implement 
them are commonplace in AI applications. The novelty is that the notion has 
been made explicit, and, in a modest sense, put into the logical calculus. 
This prevents two problems with the usual use of the implementation 
mechanisms. First, typical Al-language "demons" (Charniak, 1972) fire off in 
the middle of primitive data-base operations and get complete control of 
operations. Without conventions, it is difficult for other processes to know 
uhat the intentions of these little monsters are. 

Second, policies are to be used to express things like "loop invariants" 
and "program assertions" (Floyd, 19G7) , which are usually extraneous to actual 
program text and only indirectly related to individual program steps. But a 
problem solver has need of the notion of a "partially-reduced" problem, some 
of whose subtasks have not been fully reduced to primitives. This is 
difficult to capture without the concept of a policy. For example, consider a 
program to count the prime numbers in a table. The text of the program 
contains instructions to initialize a counting variable and increment it just 
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after a prime number has been discovered. The purpose of this variable may be 
expressed by an invariant of the form M x is the number of primes in the part 
of the table already looked at." Uhat I am trying to capture is the notion of 
an early, unfinished version of the program, in which the pieces of text do 
not yet exist, and the invariant is all there is. 

A plan is, in a sense, this kind of unfinished program, with the 
difference that it gets executed without ever getting completely written. 
Comments on a plan are not there to explain an existing text or to help prove 
that it works; they are there to explain an ongoing course of action, and they 
must be executable. Their individual steps may indeed involve initializing 
and incrementing counters; these will become subtasks of the policy. 

I wil) conclude this section by listing some limitations of this plan 
calculus. These fall into two categories: bad limitations and good 
I imi tations. 

The bad limitations are those due to the fact that I knew the plan 
language was going to be used for designing and I didn't have the time to 
implement unnecessary features. So I didn't put in features such as other 
agents' plans, or notions like "prerequisite of an action." These and other 
inadequacies are described at slightly greater length in Chapter VI. 

The good limitations are those arising from these goals: 

(1) Deductions about plans ought to be simple and shallow, 

(2) New knowledge must be expressed in a notation compatible with old. 

By deductions about plans, I mean deductions about current plans, not "proofs 
of plan properties." (Cf. Sect. VI. C) It ought to be easy to deduce what you 
are doing. Otherwise, the executions of subplans cannot interact, and the 
notion of policy will be meaningless. The second requirement is related to 
our desire for flexibility. New knowledge is worthless unless it is expressed 
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in a familiar language. There should be just one obvious way to express any 
g'iven piece of control information. (Keep this in mind as I expand on the 9et 
of control concepts in the following sections.) 

An example of a good limitation is that no loops and conditionals are 
allowed in the language. That is, all iteration and testing is done in the 
deducer. There are no gotos in the system. There are instead much higher- 
level concepts like "choosing." It remains to be seen whether I have been 
successful in inventing transparent but powerful control ideas. (I should 
mention that recursion is not forbidden in the system; a plan-schema instance 
can have sub tasks derived from an instance of the same schema. It probably 
should be forbidden, in this general form; I use it sparingly.) 

II.B Interpretation and Inference 

One thing to do with the predicates I introduced in the last section is to 
put them in axioms and prove things with them. For example, many of the 
electronics and design facts in Appendices 2 and 3 have conclusions of the 
form t/:TASK ...], meaning, "I should be doing ...." Clearly, a system which 
just proved things of this sort without acting on them would be a perfect 
catatonic. Its deductions would occur in a void. Their full meaning depends 
on there being an "action system" which interprets the result of such 
deductions as commands to act. I will call formulas like thi9 which directly 
influence action pragmatic formulas; the characteristic functions of these 
formulas are pragmatic functions or, more specifically, pragmatic predicates. 
I have already observed the convention that the names of such functions and 
predicates always start with "/:" to emphasize that their meanings depend 
mostly on the action system. In this section I wi 1 1 introduce more of them. 
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(A complete catalog appears in Appendix 1.) All predicates not directly 
influencing action mean, in some sense, only what the axioms they appear in 
say they mean. 

In this section I describe the operation of the interpreter and the 
theorem prover it uses, called STP. 

I I.B.I The NASL Interpreter 

The outer loop of the interpreter is to 

Pick a task to work on; 
If it is pr i mi tive, 

Execute it or elaborate itj 

Otherwise, find a way to work on it ("reduce" it)j 
Repeat until there are no more tasks 

The first step of the interpreter cycle, "picking a task," is done by a 
system of forward deduction of /:SUCCESSOR relations. The axioms that support 
these deductions are the user's responsibility. The system chooses at random 
from the tasks that it is logically permitted to do next. 

Much of the work is in the second arm of the conditional. The existence 
of this step is what makes NASL a problem-reduction problem solver instead of 
a programming- language interpreter. Reducing a task involves a call to the 
theorem prover STP and some more powerful mechanisms. (Sect. 1 1 .CI 

1 1. B. 1.1 Selecting a Task to Uork On 

The NASL interpreter interleaves planning and execution of plans. (Cf. 
(Nilsson, 1973).) Different tasks are in different states, which change as 
time passes. The current state of a task is composed of its task-status, its 
enablement status, and, for problematic tasks, whether it is reduced. (Fig. 
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1 1.4) Uhen a task is created, its state is PENDING and BLOCKED. Uhen a 
PENDING task is ready to be executed, it becomes ENABLED. Uhile it is being 
Morked on, it is ACTIVE. Uhen the interpreter is through with it, it is 
FINISHED. The status of a task is expressed in a formula of the form 

[-/> ' I/: TASK-STATUS |taskname|) |status|J 
where status is one of the three states I gave. 
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Figure 1 1.4 Life History of a Task 
Meanwhile, as a task evolves, i ts enablement status changes to "gate" its 
subtasks and successor tasks. Recall from Sect. II. A that the order of 
execution of tasks is constrained by /:SUCCESSOR relations. In addition, 
subtasks of a task may be deduced before the task i tse I f becomes active; the 
subtasks must be postponed. So there are three facts that must be true before 
a task can be enabled: all its super-tasks must be ACTIVE; all of its input 
pvars must be known; and all of its predecessors must have enablement status 
"successors enabled." (Fig. 1 1. 4) Uhen a task is FINISHED, its successors 
are always enabled, but the system must be flexible enough to allow execution 
of successors to begin before this. For this reason, I introduce the 
independent concept of enablement status, 

[-/> * (/:ENAB-STATUS | task name|) |status|J, 
where status is BLOCKED, ENABLED, SUBS-ENABLED, or SUCCS-ENABLED. These flags 
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are synchronized with the ordinary task-status as shown in Fig. 1 1. 4. As a 
task- becomes active, the system checks its subtasks, and enables all those 
with no other impediments; similarly, when the task enters SUCCS-ENABLED mode, 
the system checks its successors. (It should be clear that if a task has two 
predecessors or super-tasks or some combination, all must be in the proper 
state.) 

A useful service provided by the system is that as soon as all the input 
pvars of a task are known, whether or not there are other gating conditions 
remaining unsatisfied, a formula of the form 

[/: TASK-ACTION | task name| |action|J 
is recorded in the data base. 

Figure 1 1.4 also shous the transition of a problematic task from being 
"unreduced" to being "reduced." Uhen a task has been completely replaced by 
subtasks, the proposition 

[/: REDUCED | task name|] 
is supposed to hold true of it. The system will not bother to reduce a task 
if such a formula has already been deduced; this enables task netuorks to be 
built up entirely by forward deduction. 

I I.B.I. 2 Executing Tasks 

Uhen a task has been selected, it must be executed. If its action is of 
the form [|f| ...], I cal I f Its act f on function. The system can tell by 
looking in the data base or on the property list of f whether the task is 
primitive or problematic. If it is problematic, it must be reduced. 
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1 1. B. 1.2.1 Primitive and Problematic Tasks 

An action can be primitive in one of two ways: its action function can 
have a defining LISP function on its property list, or it can be defined by 
model-manipulation axioms. The latter are looked for first. 

The interpreter calls STP to deduce formulas of the form 

[/:M00-riANIP | task name| |action| 7DELETELIST ?ADDLIST1. 

where the variables 7DELETELIST and 7AD0LIST are intended to become bound to 

tuples of "senses," or quoted facts. (See Appendix 1.) For example, we might 

have 

[(ON ?X ?B) o 
(/:t10D-MANIP 7TASK (HOVE ?X ?A) <' (ON ?X ?B)> <' tON ?X ?A)>)1 

in the BLOCKS world. The meanings of the addlist and deletelist are the 

traditional ones. (Fikes and Nilsson, 1971) The model (data pool) is to be 

updated in the obvious way: the formulas represented by the elements of the 

deletelist are deleted, and those represented by the addlist are added. These 

manipulations are called roode7 effects. 

If the primitive has a defining LISP function on its property list, that 
function will just be executed. It can do something, return a value, 
establish a policy, or annex a subnet. An example of the first kind is the 
action IGRABBA |property|] in the design world, which creates an object with 
the property. Values are returned by deductive actions like /:FIND, which 
call STP to retrieve data. 

The most important kind of primitive is the "macro," which annexes a 
subnet. The typical member of this class is 

[/: DO-SUBNET |plan schema | |vars-mapp. 
which is used to instantiate plan schemata and hang them off the net. 
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In the current implementation of NASL, plan schemata are not represented 
as identifiable objects. Instead, they are defined implicitly through 
statements of the form 

t(/:PLAN-INSTANCE 7NAI1E |plan schema| 7SUPER-TASK) 
d (AND (/:TASK |subtask 1| ...) 
(/:TASK jsubtask 2| ...) 

• • • 

(/tSUBTASK Isubtask 1| 7SUPER-TASK) 
(/:SUCCESSOR Isubtask 1| Isubtask 2|) 
-other connectivity relations-)] 

by which nets of subtasks are created and linked together. Executing /:D0- 
SUBNET creates a new plan instance and records 

(/: PLAN-INSTANCE |plan instance name| |plan schema | | super task|]. 
This will trigger the forward deduction of subtasks in the schema. 

These subtasks will compute and use the values of plan variables 
("pvars"), some of which the super-task network needs; the vars-map argument 
of /:DO-SUBNET tells how to map the schema's variable back to the calling 
plan. To make this work, all the pvars used by the tasks in the schema must 
be of the form [(|var name| |plan instance name|)J. (For an example of the 
use of /:D0-SUBNET, see the formulas +0ESI-1 and +DESI-2 in Appendix 2.) 

A macro-expanded task will be FINISHED when all its subtasks are. It will 
have enablement status SUCCS-ENABLED when all of its "main" subtasks are 
FINISHED. This device is intended to capture the idea of a task reducing to 
two kinds of subproblem: things which must be done before going on to the 
successors of the task, and things which can wait. An example is biasing one 
stage of a complex circuit (see Appendix 3); this will appear as a subtask of 
acquiring a circuit, but it should not be done when the circuit is first 
obtained; instead, it may become a successor of, e.g., coupling the circuit 
to something else. Subtasks labeled /:MAIN are those whose completion is a 
necessary condition for enabling a supertask's successors. (See Fig. 1 1.5.) 
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Figure II. 5 Enablement Relations in Subnets 
This is one of the ways in which the subtask relation differs from the 

usual relation between a program step and its program. 
Other macro actions are described in Appendix 1. 
This concludes my description of the execution of macros and other 

primitives. All other tasks have "problematic" actions. In such a case, NASL 

calls STP with the request 

[/: TO-DO | task name| |action| < -output vars- > ?UAY] 

If STP returns exactly one value for ?UAY, a new task for the new action is 

created, enabled, and made the /sMAIN subtask of the current task (which 
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becomes /: REDUCED). If STP does not return exactly one value, special things 
must' occur which are the topic of Sect. II. C. 

1 1. B. 1.2.2 Primary and Secondary Tasks 

Primary tasks are those which do something or infer something. Primitive 
primary tasks are those defined by /tMOD-MANIP and inferential functions. 
Secondary tasks {"policies") are those which influence the execution of 
primary tasks. 

The principal primitive policy is 

[/MONITOR |formula| (A (\v\) |action|)], 
which does nothing unless some task removes the formula as a model effect. 
Then a new subtask will be created with the given action, with v bound to the 
task that did the removal. This is used to implement protection. 

Policies may cause the "intermittent" execution of primary actions. A 
task with action [/rCONTINUE Ipolicy task| |action|) will be executed in a 
nonstandard way. It causes a deduction of the form 

[/:TO-CONTINUE Ipolicy task| |action| <> ?UAY1 
and the resulting sub-action is attached to the original policy task node of 
the task network. (See the implementation of protection described in Chapter 
III.) Thus a policy may occasionally cause execution of real actions in the 
process of executing /: CONTINUES. 

A problematic task may also be primary or secondary. This is not 
determined when the task is reduced, but after its /:f1AIN subtasks have been 
set up. At that time, if any of its subtasks are discovered to be secondary, 
and to have a scope larger than it, it is declared to be a policy. 

The main difference between the execution of primary and secondary tasks 
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is in how they are finished. A secondary primitive will not be finished until 
the task which is its scope is finished; then the interpreter executes 
l/:FINISH |policy|] to clean it up. Problematic tasks of both kinds are 
finished when all their subtasks are. 

Here is a summary of the ways in which policies influence primary actions: 

(1) The primitive policy /tflONITOR is used to implement things like 
"protection." (Sussman, 1975) 

(2) The presence of formulas regarding the status of a task can license 
deductions of various sorts. The conclusions can be of the form [/:TASK ...1 
and I/:T0-D0 ...1, for example, and thus trigger things to do and ways of 
doing them. 

(3) In particular, policies often influence the "choice protocol" 
described in the next section. 

(4) The use of /:C0NTINUE can cause intermittent execution of primary 
actions. 

Uhen policy-specifying formulas influence the interpreter's deductions, it 
will record their influence in the form of /:SUBTASK assertions. That is, 
when /:TASK formulas are deduced from policy task formulas, they become 
subtasks of those policies. (Sect. II. D) Thus, a natural structure evolves 
in which a task can be a subtask of "make a filter" (primary) and "keep the 
cost down" (secondary). 

II.B.2 STP — The Stupid Theorem Prover 

STP is a backward-chaining, pattern-matching theorem prover. In R. 
Moore's (1975) phrase, it is a procedural deductive system. Such a system may 
best be thought of as a descendant of PLANNER (Hewitt, 1972) which emphasizes 
its logical aspects instead of emphasizing its programming- language features 
as most other descendants have done. By this I mean that it manipulates, not 
arbitrary list structures, but formulas that are supposed to represent 
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statements about entities. There are no side effects during deduction; the 
acHon system is completely divorced from the operation of the theorem prover. 
This means that the theorem prover can be optimized in various special ways. 
(See Appendix 4.) 

STP is used by the system for two kinds of deductions: those about tasks 
and actions and those about the physics of the problem domain. 

STP is not particularly bright} it is to be used for information 
retrieval, and it tends to balk at intricate reasoning. More sophisticated 
reasoning is done as inferential tasks. (There are things to regret about 
this organization. See Sect. VLB.) Some kinds of reasoning do not naturally 
fit into the theorem-proving paradigm at all. These will be discussed in 
Sect. I I.C. 

Actually, "theorem prover" is a very misleading term. The "theorems" such 
programs prove would not be recognizable to a mathematician; the way in Mhich 
they go about it would be even more incomprehensible. Nonetheless, I will 
continue to use this term, since by now AI people are unlikely to read 
anything very pretentious into it. 

A theorem prover may be thought of as a problem-oriented interface between 
a problem solver and bare data-base machinery, such as that described in 
(McDermott, 1975). For example, an AI data-base manager implements the notion 

of "data pool." This will be used to implement the higher-level notions of 
"packet" and "reference point." (See below.) The calculations involved can be 

made invisible to the user, who thinks in the higher-level terms. 

The basic data-base operations are three: putting things in, taking things 

out, and finding things. These are handled by the three primitive (LISP) 

operations RECORD, ERASE, and STP. RECORD puts a formula into a data pool. 

It also does forward deductions from that formula in a way to be described. 
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The results of these deductions are recorded also, and conclusions are linked 
by "data dependencies" to the formulas which support them. (See Sect. II.D.) 
ERASE flushes a formula and everything it supports from a data pool. 

When proving theorems, STP works, like every other "theorem prover," by 
matching goal formulas against "knowledge" formulas, detaching the output, and 
repeating until a proof from atomic data is obtained. (Cf. (Bledsoe, 1975) 
For technical reasons (R. Moore, 1975), STP really attempts to refute the 
negations of goals. See Appendix 4.) 

Formulas are stored in the data base in clause form. Clauses are 

implications whose format tells how they are to be used. The two most common 

forms are 

[-/> C \p\ |q|l, meaning, "to prove q, prove p" 
and (-/> A jpj |q|], meaning, "if p is recorded, record q. " 

(These correspond in an obvious way to Planner's consequent and antecedent 

theorems. (Hewitt, 1972, Moore, 1975)) The arguments p and q to these 

predicates can be clauses as well; my clauses have more pragmatic structure 

than those of a resolution theorem prover. (Robinson, 1965) 

Internally, these clauses are stored as (pragmatic) disjunctions of the 

form 

t/:C0NSEQ \q\ (NOT |p|H 
and [/tANTEC (NOT |p|) |q|l 

respectively. These forms are occasionally useful externally as well. 

A third pragmatic disjunction is /:GEN. l/:GEN \p\ |q|l, when "recorded," 

really causes counterexamples to p to be found and, for each one found, an 

instance of q to be recorded. This may be also be expressed [-/> G (NOT |p|) 

|q|]. For example, recording 

[-/> G (DEV-TYPE ?X COMMON-EMITTER) 
(DEV-TYPE ?X AMPLIFIER)] 
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calls STP to find all common-emitters and record that they are amplifiers. In 
this- way backward deductions may be triggered in the midst of forward 
chaining. 

STP is oriented toward the task of information retrieval. Uhen given a 
goal with free variables, it doesn't interpret i t as a request to prove that 
objects exist which would satisfy the formula if substituted in; instead, it 
considers it a request to find and return these objects. This is like PLANNER 
(Hewitt, 1972) and QA3 (Green, 1969a, b). (See Appendix 4.) 

For example, given the clauses 

IP A] 
IP B] 
[Q Bl 

t-/> C (AND (P ?X) (Q ?X)) 
(R ?XH 

and the goal: Refute [NOT (R ?YU, 

STP chains backward through the consequent clause to generate as subgoal 

Refute [NOT (ANO (P ?Y) (Q ?Y))J. 
This becomes two "conjunctive goals"; "Refute [NOT (P ?Y>] " and "Refute [NOT 
(Q ?Y)J." STP finds Y -* A and Y -» B as answers to the first goal, and 
detaches [NOT (Q A)] and [NOT (Q BU as alternative versions of the second. 
Only the latter of these succeeds. The returned answer is therefore Y -► B- 

The machinery to make this work reasonably well is described 
in Appendix 4. 

Some other interesting features of STP are these: 

(1) Ability to call LISP functions for low-level deductions. (Cf. 
(Nevins, 1974a, b).) I have made an effort to keep alt such LISP-implemented 
concepts completely primitive and domain- independent. These are concepts for 
manipulating simple inequalities, predicates on embedded formulas, etc. 

(2) "Non-monotonic" inference rules, which are implemented by having 
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certain predicates be evaluated by calling STP recursively. For example, 
[/: CONSISTENTLY * |pattern|J will be handled by calling STP to see if pattern 
can be refuted. (The single quote is used to flag an expression within which 
substitution of equals for equals is forbidden; such an expression is called a 
"sense.") McCarthy's "presumably" operator (McCarthy and Hayes, 19G9) is 
defined as 

[(PRESUMABLY '?P ?USE) ■ (-/> ?USE (^CONSISTENTLY *?P) ?P)3 
meaning, "if you can't prove ?P is false, assume it's true." Thus we have, [VX 
(BIRO ?X) d (PRESUMABLY (CAN ?X FLY) C)], which means, "If X is a bird, then 
if you ever need to check if he can fly, assume he can if you can't prove he 
can't." (If the formula had had "G" instead of "C," the attempt to refute his 
ability to fly would be done at the time he was deduced to be a bird.) 

(3) Pragmatic handling of equality. The usual predicate-calculus notion 
of equality does not correspond very closely to the programming notion of 
evaluation. If you ask a theorem prover, "Find ?x such that 2+2 = ?x," it 
will tell you, "?x - 2+2," which is true but useless. An action module 
communicating with a deductive system must have the concept of "useful 
expression." In the midst of problem solving, some data structures are 
inherently more oriented toward getting on with things. Consequently, STP 
works closely with an evaluator (see Fig. 1.9), which applies rewriting rules 
found in the model to expressions, we have already seen these rules in action 
implementing pvars. They look like [«=/> '(+2 2) 43. The "sense" quote is a 
way of forbidding applying the rules to subexpressions. (Otherwise, the rule 
would rewrite itself as t-/> 4 41.) 

The evaluator is used by the interpreter, by user plans which use the 
/zEVAL primitive, and by STP. (See Appendices 4 and 5.) Normal equality, 
t" I x I lyN. is used to express goal 9 like, "prove tuo things are equal." 
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There is a "cheap" equality predicate called ":-". The only knowledge about 
it is [:- ?THING 7THINGJ. It is used in conjunctive subgoal3 to "set" 
variables for future use. That is, the goal [;. ?X (F00 BAR)] succeeds, 
setting ?X to [F00 BAR]. The system will not waste its time trying to prove a 
goal like this if it doesn't succeed immediately. 

When an equality is recorded in the course of trying to prove x and y 
unequal, the system makes an effort to translate it into a rewriting rule; 
otherwise, it will never interact with other deductions. Cf. (Bledsoe and 
Tyson, 1975). 

(4) "Packets." It often inconvenient to have to record a large 

conjunction as a consequence of some forward deduction. For example, in 

electronics, devices are of various types. If it is recorded that [DEV-TYPE 

OEV073 COMMON-EMITTER], this might trigger the recording (via "-/> A") of 

scores of facts about DEV#73. most of which will never be looked at. This can 

be avoided by writing the relevant antecedent implication as 

[-/> A (DEV-TYPE ?CE COMMON -EMITTER) 
(/:PKT CE-PKT (?CE) 
I fact 1| 
I fact 2| 

• • • 

Ifact n|)J. 
As explained in (McDermott, 1975), defining this formula will create a packet 
which plays the role of the large conjunction uith one free variable ?##CE. 
It is actually implemented as a "data pool layer" which can be added cheaply 
to the current data pool. The individual facts will be closed and indexed 
only as they are accessed. 

(5) A "modal" notation and inference mechanism. A general deductive 
system should be able to reason about hypothetical situations, other times, 
other creatures' beliefs, etc. These concepts are in the domain of "modal" 



II Expressing Knowledge in NASL 70 



'ogic (Hughes and Cressuell. 1972), a difficult study with .any problems. I 
have implemented a modest system for doing some very simple modal deductions. 
Mhich uses the "data pool" mechanism to implement "reference points." 
(Montague, 1974, Rescher and Urquhart, 1971) 

The basic modal notation in the NASL language is [T Inference point| 
Itermp, which stands for the value of the term with respect to the given 
reference point. In principle, these reference points could be other 
creatures' minds, arbitrary points in time, or just "possible worlds." Under 
this last interpretation, logical necessity might be taken to mean [VR (T ?R 
— U. or «... is true in all possible worlds." However, this would require 
quantifying over reference points, a capability I have not had the time to 
pursue. Instead, DESI confines itself to the use of constant reference 
points. These are used (see Chapter IV) for things like the DC and 
einusoidal-steady-state models of an electronic circuit. 

This sort of mechanism is just a convenient notation for data pools (i.e.. 
"contexts") from within the logical language. To make it work, I have 
introduced some notation for "frame" axioms. (Hayes. 1973a) A reference point 
is often defined in terms of the differences between itself and some set of 
super reference points from which it inherits most of its contents. These 
definitions are written thus: 

r^n^rr^r -cr The vz ; *~ %•«• 

[(FRAME ?REF 7FRAME-REFS) = 
(VP (3F (?F e 7FRAME-REFS) a (T ?F ?P)) 
:> (PRESUMABLY ' (T ?R P) C))] . 

con.?^";d , u.!™\Vl'?iS; nte - " V M9 Way> IPStead « a ne » data P°°' »» 
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[N |reference point| * | fact |] means that the given fact is not inherited 
from the reference point's frames. 

Formulas of the form IT |reference point| | fact 1 3 are used in constructing 
new reference points. Any such propositions lying around have their facts 
shoved into the new data pool. 

Examples of the use of these formulas are given in Chapter IV. 
II. C Choice and Rephrasing 

As sketched so far, NASL resembles some more familiar problem solvers. 
Except for the imposed distinction between deduction and action, it is a lot 

like PLANNER. (Heuitt, 1972) The wain difference is that it does no 

backtracking past model manipulations. Since it is more disciplined in many 
Mays, it is better able to explain its actions. 

However, it suffers from some of the same problems as PLANNER-like 
systems. In particular, a certain amount of the additivity I wanted will not 
be found in this organization. Even though it is easy to add a new plan 
schema to a body of facts, the interactions of this new material with the old 
are not so easily handled. 

For example, if acquiring a common-collector amplifier is known to be a 

good way of achieving high input impedance, this fact might be lying around in 

a formula of the form 

["high input impedance required" 
d (/: TO-DO ?T MAKE AMPLIFIER) <?N> 
(MAKE COMMON-COLLECTOR) ) J . 

(For a precise version of this, see Appendix 3.) Now, say that the system is 

to be told about field-effect transistors (FETs). Since they have a high 

input impedance, an exactly similar fact will be recorded regarding the FET 

common-source amplifier. 
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Now a request to make an amplifier Mill cause both these facts to be 
retrieved. What can be done? (we have already ruled out just trying one 
until it fails.) One approach would be to force the user to revise one or 
both of the formulas to check for information that will distinguish between 
the two case9. However, this will lead to large, impenetrable implications. 
Furthermore, in some cases of such confusion, neither choice is preferred, but 
9ome synthesis of the two. Ue need a way to represent such "differential 
diagnosis" and "partial-solution composition" knowledge in an additive manner. 

The solution is to face up to the necessity for treating "choice between 
alternatives" as a basic situation of problem solving, and to create new 
pragmatic predicates for handling it. This is the subject of Sect. 1I.C.1. 

The complementary problem that this brings to mind is when the deductive 
pattern-based backward chaining of STP is unable to retrieve any possible 
plans. This might be because there aren't any, and the user must provide new 
information, but it also might be because the relevant retrieval strategy 
depends upon pattern-manipulation operations which are less disciplined than 
unification. For example, we might want to express, "If the problem mentions 
MHz, try special high-frequency heuristics." Here the traditional AI language 
solution is to allow arbitrary list-processing operations upon formulas. (The 
traditional predicate-calculus solution is to do aimless equality 
substitution.) Thus, in C0NN1VER (flcOermott and Sussman, 1973) a method with 
pattern (LAMBDA !>X !>Y) can match the calling pattern (LAMBDA (X) (F (G X))) 
and do anything it likes uith the pieces so generated. This is somewhat 
abhorrent, since i t tends to destroy the notion that formulas mean anything. 
Who can rule on the consistency of a set of formulas that do things like that? 

My approach to this problem is to try to impose some discipline on this 
kind of manipulation. The idea is to signal explicitly when the system is 
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allowing itself to do things like that, and to impose restrictions on its 
behavior and the results it computes. This idea is developed into the 
"rephrasing" protocol of Sect. II.C.2. 

I I.C.I The Choice Protocol 

Under some circumstances, STP is asked to return all the answers it can 
find (cf. Appendix 4), but it can be asked to return just one. In thi3 
situation, if more than one answer is found, the system performs a ritual 
invocation of information about choosing between them. This is called the 
choice protocol. For example, this protocol is called when DESI finds more 
than one possible circuit for a general concept like "amplifier." In that 
case, detailed information about the various types of amplifier interacts with 
information about what is required of this amplifier to force a choice. 

The first thing the chooser does is to create an (abstract) choice 

situation name and record in the data pool 

[/rCHOICE |name| |context| |goal formula|] 

(The context is the inferential task for which more than one answer is found. 

In the case of the interpreter trying to deduce how to do something, this 19 

just the symbol "EXEC") For example, in trying to choose an amplifier, it 

would record 

t/: CHOICE C0535 EXEC 

t/: TO-DO TSKM37 (HAKE AMPLIFIER) <* (STAGE1 CKT#747)> 
7UAY] ] 

The formal resemblance of this to /:TASK formulas is suggestive; we have in 
effect added a new kind of entity, the choice. The intent is that this 
formula will trigger forward deductions of the kinds to be described in a 
moment. The packet machinery of (McOermott, 1975) will allow the system to 
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bring in large packets of ghat may loosely be called "advice" appropriate to 
this situation. 

The use of "brackets inside brackets" is our first encounter with the 
concept of "embedded Formula." (See Appendix 1). The system is treating the 
goal here as a data structure to be analyzed. 

For each of the possible answers, a formula of the form 

[/:0PTI0N | choice name| | opt ion name| | answer formula |] 

is recorded in the data pool. For our amplifier example, we might have 

t/: OPT I ON C#535 A0450 

[/: TO-DO TSK0437 (MAKE AMPLIFIER) <' (STAGE1 CKT#747)> 
(HAKE COMMON-COLLECTOR) 3 1 

[/:0PTI0N C#535 A0451 

t/:T0-D0 TSK#437 (HAKE AMPLIFIER) <* (STAGE1 CKT#747)> 
(MAKE FET-COMMON-SOURCE)]] 

Recording these formulas will trigger the deduction of formulas of the 
form 

[/: RULE-OUT | opt ion name|], 
[/:RULE-IN |option name|], 
or [/: RULE-TOGETHER < -option names- > |new answer formula|]. 

The system first searches for conclusions of the form l/:RULE-OUT ...]. 
This is a call to STP, of course. If any are found, the options ruled out are 
removed from consideration. Next, the system looks for conclusions of the 
form t/:RULE-IN ...]. If any of these are found, the system throws away all 
options except those mentioned. Finally, it looks for /:RULE-TOGETHERs. If 
one of these occurs, the options it mentions are discarded in favor of the new 
answer formula. 

If at any stage all options but one are eliminated, the protocol stops 
with a winner. If all the options are ruled out, the system enters an error 
protocol to show the user what it did and ask for corrections of its 
misinformation. If more than one option survives, the system records 
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[/: QUIESCENCE | choice name|) 

in an effort to trigger more forward deductions. 

The intent of these devices is clear. Differential diagnosis is to be 

performed by the first two kinds of formula, while /:RULE-TOGETHERs are 

intended to be one locus of composition of partial solutions in the NASL 

system. (The others are problem reduction (see above) and error correction 

(see Sect. Ill .01 in the context of patching electronic circuits.) The 

VtQUIESCENCE trick enables the user to encode advice of the form, "All other 

things being equal...," as a forward implication like 

[-/> A (/:QUIESCENCE ?C) ...J. 

The choice protocol keeps track of the rules which contribute to weeding 

out all but one option. These rules are used in building data dependencies 

(sect. II. D). In addition, when a policy is used in choosing a way to do 

something, the choice is made a sub task of that policy. For example, say 

there is a policy of the form "keep costs low," plus a deductive rule like, 

*Uhen trying to make a device, and trying to keep costs low, then, all 
other things being equal, if a circuit with inductors is competing as an 
option against a circuit without them, the one with inductors is ruled 
out." 

Now if the task of constructing some circuit is elaborated into a device 
chosen on the basis of this rule, the task of acquiring the device is subtask 
of both the construction task and the costs policy. This leads to clear 
explanations by the system of its behavior. (Sect. V.A) 



(The choice protocol was inspired by the design of Marcus's (1973, 1975) 
"wait-and-see" parser, which does similar things in choosing directions in 
which to parse.) 
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I I.C. 2 Rephrasing 

I now turn to one of the most important and least elegant subsystems of 
NASL, the rephrasing protocol. This is the system which is invoked when STP 
is unable to find a reduction of a task. Rephrasing consists in treating the 
recalcitrant problem as an object to be transformed into a new problem. The 
pious hope is that the new one is easier. This, of course, is precisely the 
object of task reduction in the first place. So rephrasing may be thought of 
as taking extraordinary measures to reduce a task. 

The way this works is as follows. Uhen the system is unable to find a way 
/:T0-00 something, a task 

I/: TASK | name | <> 

(A (/:REPHRASE |task| |action formula| < -output pvars- >)) <>J 

is created, and made a predecessor of the losing task. This task is allowed 

to carry out arbitrary inferences in order to reduce the unreduceable task. 

For example, the design task DES#78, with action 

[DESIGN (X (X) (AND (IS AMPLIFIER ?X) 

(- (VOLTAGE-GAIN ?X) 180)) )) 

is unlikely to trigger an indexed solution. Instead, it must be rephrased as 

some set of simpler actions, by the use of electronics knowledge. So the task 

[/:TASK T#8A9 <> 

(* (/: REPHRASE DES078 

[DESIGN (A (X) (AND (IS AMPLIFIER ?X) 

(- (VOLTAGE-GAIN ?X) 108)) )I 

<|resul t pvar|>) ) 
<>) 

Mill be put in the task network as a predecessor of the design task. Its 
effect will be to reduce task DES#78. 

The rephrasing protocol must exist in order to provide for deductions 
beyond the scope of STP's simple strategies. These fall into tuo categories, 
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one more elegant than the other. First, because it uses the interpreter, it 
can take advantage of the choice protocol, flexible planning and policy 
making, and even recursive rephrasing. Thus, for example, one can make finer 
choices than is allowed by just running the chooser on a set of possible 
reductions. 

Second, and less happily, the rephrasing protocol manipulates the action 
formula as an "embedded formula," and so is allowed to perform any operation 
on its representation. So one can write rephrasing plans which check to see 
if the given action refers to "UIDGETS" anywhere. In the next chapter, I will 
show how, in the course of rephrasing design problems, A -expressions are 
routinely dismembered. This seems to be indispensable, but it would be nice 
if we could insist that the pieces be put back together in a legitimate way. 

This is a special case of the more general problem of making sure that the 
interpreter and inference mechanisms actually do what they are supposed to do. 
The difficulty is in specifying what the object of a task or protocol is. For 
choice, the object is fairly clear: eliminate all but one option. (Inelegancy 
creeps in with /:RULE-TOGETHERS. ) Efsewhere in the interpreter, I have 
ignored this very important problem, except for token checks such as that 
/:FINISH actually leave its task finished. In the case of rephrasing, the 
problem is especially acute; rephrasing can be thought of as a device for 
extending the pattern matcher by allowing arbitrary deductions about formulas. 
Something like this is necessary, but it should be better constrained. 

As it is, there are only a few restrictions on the use of rephrasing: all 
the actions undertaken as sgbtasks of a rephrasing must be inferential, not 
worldly; the rephrasing task must leave its target task /:REDUCEO; and the 
subtasks resulting from a rephrasing must be syntactically legal (i.e., not 
contain X's in funny positions or have any free variables, etc.). 



II Expressing Knowledge in NASL 78 



The rephrasing knowledge for the design domain, which I present in the 
next chapter, is an example of what rephrasing ought to be. The formulas 
involved are reduced to pieces by one task, and parsed together again by 
others. I hope that this will prove to be an instance of some more general 
recognition strategy that is more constrained than what the system now allows. 

I have now described every module in Fig. 1.9. The search paradigm that I 
have developed may be summarized as: let the theorem prover search, but not 
too far or too deeply. All searches are intended to be short and sweet; the 
search is used for exactly those spots where there is no applicable knowledge. 
These short searches are organized by a plan interpreter, which decides what 
9ort of knowledge is to be accessed. It can ask for answers to questions 
about how to do things, the physics of the domain, choosing among 
alternatives, or transforming its oun problem statements. Thus, as far as the 
paradigm has been developed, it is in accordance with R. Moore's (197S) 
observation that theorem provers are most naturally applicable to information 
retrieval problems, and that other control structures are needed for more 
sophisticated tasks. 

II.D Dependencies Among Data and Tasks 

•It i9 becoming generally realized that AI systems must record their 
reasons for their conclusions and actions. (HcDermott, 1974a, Stallman and 
Sussman, 197G, Shortliffe, 1976) These records have many uses: 

(1) They can be used to explain reasoning and actions to a human user. 

(2) They guide the system in undoing faulty deductions. 

(3) They are a guide to correcting the effects of misguided actions. 
(A) They can be used in assigning the blame to incorrect rules. 

The basic relation among data is the deductive data dependency. 
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(McDermott, 1975) Every time STP or RECORD does a deduction, it attaches such 
a dependency to the conclusion and the premisses; the latter become the 
supporters of the dependency, the former, the supportee. (See Appendix 4.) 
Uhen the system does an ERASE, all the supportees of the erased item are 
erased themselves if they have no remaining supporters. 

These support relations are accessible to the problem solver as a set of 
LISP- implemented predicates. In particular, 

[/: SUPPORT < -formula names- > | formula name|] 
is supposed to be true when the indicated dependency holds. 

These support dependencies are also created by the inferential action 
/:INFER (see Appendix 1>. Other inferential tasks call STP and let it build 
dependencies. 

These devices account for the second in the list of uses of dependencies 
among data and tasks. The others are more complicated, because they involve 
the relation between action and the world model. Here are examples of the 
kinds of relations that can occur: 

(1) A task can have model effects. The relation between the task and its 
effects is non-deductive because erasing a task is not sufficient to undo its 
effects. (Besides, some of the effects are erasures.) 

(2) A task or pvar value can be based on choice information. Ue want to 
record this relation, but erasing the basis of a choice does not erase the 
choice, although it calls the wisdom of the choice into question. 

(3) Fact9 in the current model can support task statements. A fact about 
circuit topology supports a constraint on the physical quantities it 
influences. Erasing such a model-effect formulas should cause the task 
formulas to be erased too, 

(4) Facts in the current model can trigger tasks. Th'19 is a quite 
different situation from (3). NASL implements the common AI mechanism of 
"demon" or "pattern-triggered interrupt" by allowing /.-TASK and /:SUBTASK 
formulas to be deduced. For example, a BLOCKS-world system may for a time 
have a policy to the effect that a certain block B#72 is to have a clear top. 
This get9 translated into the principle, 
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(VX (ON ?X B072) 

3 (3T (/:TASK ?T <> (A () {REMOVE ?X B#72)) <>))] 

^L^ 74 /^ 6 ^* ",^ 72 ' ™ S Wi " Create a task to take !t »"• A model 
effect of this task is the erasure of (ON B074 B#72) and with it the task' 

mi 9 contradicts common sense, since once the interpreter starts to work on 
something its success should not erase it. There may even be serious errors 
! JIiTT ? 9 V Ch an erasure - sin ce the erased task may not have been 
completed yet. In any case, the user may want to ask questions about tasks, 
without worrying about which ones erased themselves. 

It is clear that this problem has to do with the treatment of time. An 
• u J? ^ 6ecome a task for on e reason, but stay a task for another. This 
ts handled by the use of the modal operator S, defined as follows: (S 'IfactlJ 

lS a "L it St % tS .-,l° be trUe -" The =«"«: '"8 ion of the given implication 
should be C...(S GT (/:TASK ?T. . .)))]. Exactly the same fact will end up in 
tne data base, but the supporting data dependency will be different. (It is a 
bit wishful to call this a "modal operator" instead of a "patch." If the 
modal machinery Mere better developed, it could be supported by axioms like 

[T ?R ((S *?P) a ((TIME) - ?t)) 

3 (3i (VQ (T ?Q (?t < (TIME) < ?t+?i) 
d ?P)))J, 

but it isn't.) 

To represent these nuances, the structure of data-dependencies must be 
made more flexible. Before, the supporters list of a dependency was just a 
list of data; now we make it a "labeled tree" of tuples of data. Each label 
explains the role the supporters play in the dependency. For example, a 
BLOCKS-world program might execute the task 

t/:TASK (FIND-OUMP) <> 

(A O (:FIND (A (X) (IS PLACE ?X) )) ) 
<MOUriP)>] 

in order to find a place to get rid of a nuisance block. If it chooses X - 

TABLE because of a choice principle C, the result 

[-/> ' (DUMP) TABLE) 

will be supported with the two labeled dependencies! 

(DO-CHOICE (IIS PLACE TABLED (DO-CPRIN (C))) and 
(DO-INFERER (IFIND-DUMPIJ) 

where DO-CHOICE, DD-CPRIN, and OD-INFERER label the roles of the formulas they 
dominate in their trees. (I am being a little casual about the format of 
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these structures; when they are attached to the data, pointers to the 

supporting data themselves appear in place of their formulas.) 

Here are some of the implemented labels: 

(DD-ACT-RESULT (|task datum |) 

(DD-APRIN -action principles-) 
(DD-ATR1GGER -action triggers-)) 
relates a task to its results. The action principles are general 
formulas (found in the main data pool GENERAL-DP*); the action triggers are 
formulas that were true (perhaps transiently) when the action occurred. 
Erasing the latter will not disturb the supportee of the data dependency. 

(DD-CHOICE (-inferential supporters-) 

(DD-CPRIN -choice principles-) 
(DO-CTRIGGER -choice triggers-)) 
records an inference for which an answer had to be chosen. The rules 
which contributed to this selection are sorted into triggers and principles 
just the way they are for actions, but, for choices, the supportee is immune 
from disturbances to either of the kinds of choice formula. 

(DD-S (-triggers-)) 

labels supporters whose erasure does not affect the supportee. 
Deducing (S ' \T\] will record l\r\) with the supporters insulated by a DD-S 
I abe I . 

(DD-INFERER (Jtask datum|)) 

is attached to formulas deduced or inferred by inferential tasks. This 
is used by other inferential tasks to refer to those formulas. 

(DD-ISTATE (-data-)) 

is used to label formulas, like /:TASK formulas and pvar value 
assertions, which define the state of the interpreter. These formulas are 
"incorrigible," and are never erased. 

(DD-EXEC ( | task datum |) (-other data-)) 

records other miscellaneous relations between a task and a formula 

(DD-T |datapool| (-data-)) 

links data across reference points. The intent is to record that the 
presence of the data in the foreign data pool are responsible for the presence 
of the supportee (which may be a DD-T itself). 

This information can be dumped out in a revealing form, as described in 
Chapter V. 
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II.E Handling Mistakes 

Consider situations like the following: 

You are dialing a telephone number. Halfway through, you feel your hand 
slip and you know you have misdialed. 

There is a power failure. You wonder if the refrigerator will be damaged. 
You flick the kitchen light switch on to have a closer look. Nothing happens. 

Someone asks you to design an amplifier uith a certain high gain-bandwidth 
product. You confidently pick a familiar circuit topology and begin to 
compute the required component values. You discover there are no component 
values that will do the trick. 

All of these are examples of "mistakes." (A finer classification is possible. 

Cf. (Nilsson, 1973).) They all have in common, in the terms I have been 

developing, that the plan for accomplishing a certain task has been shown not 

to work. In each case, it is wholly or partly useless to continue on the 

plotted course. 

Not enough work has been done in AI on correcting such mistakes. (But see 

Nilsson, 1973, Phi I ip Hayes, 1975, Sacerdoti, 1975.) Instead, we have spent a 

lot of effort on seemingly similar search problems in which "blind alleys" are 

searched, and real mistakes never occur. I discussed this briefly at the 

beginning of this chapter. The problem with even the most sophisticated of 

mechanisms for searching through blind alleys (Stal Iman and Susstnan, 197G) is 

that they rely on the ability to restore previous choice points. Previous 

discussion of the problems associated uith this (e.g., McDermott and Sussman, 

1972) has focused on the difficulty in choosing a choice point to restore; 

here I wish to call attention to the impossibility of restoring most choice 

points in any useful way. The problem is that the range of choices previously 

available may be obsolete. Sometimes this is because some of the choices have 

been ruled out by other processes. This is handled nicely by Stal Iman and 
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Sussman's EL (1976). A worse problem is that non-monotonic inferences made at 
the time of the old choice may have been rendered incorrect by further 
discoveries or changes since the old choice. (ttcOermott, 1974a) For example, 
the range of choices available for instantiating an amplifier can change 
dramatically after adjacent stages are instantiated. There is no way to 
return to one choice point without considering all the choices and actions in 
between. 

The alternative scheme I am about to outline ha3 not been implemented, 
although many of the pieces are in place. 

The idea is to treat correcting a mistake as a task like any other. The 
mistake is given a description by the primitive that failed. (For example, if 
a constraint cannot be satisfied, the mistake is described as (CONSTRAINT- 
COLLAPSE | losing constraint!].) The system sets itself the task 

(/:GET-RID-0F |mi stake description!! . 
Often it will be necessary to re-describe the situation; this is a job for the 
rephrasing protocol. A typical electronics-domain redescr ipt ion might be 

( IMPROVE '(GAIN (STAGE089) ) ] . 
Plans are retrieved to carry this out. (Cf. Chapter I.) 

The difference between this and and a routine situation is that the task 
network must be corrected in some way. Some of the tasks that existed before 
the mistake are still "healthy," else there would be no reason to go on 
living, but some of the subtasks are now "rotten," and may be replaced. A 
subtask of a /sGET-RIO-OF task is allowed to alter certain parts of the task 
network. 

flaking the network-editing machinery work is the hardest part of 
implementing this scheme. The kinds of edits that must be allowed include 

> Adding new subtasks to correct the problem.. The commonest reaction to 
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an accidental "protection violation" (Sussman, 1975) is to re-establish the 
protected fact without further fuss. 

> Restarting old subtasks. For example, the string of tasks involved in 
dialing the first digits of a misdialed telephone number must be resurrected. 

> Detaching and redescribing old subtasks. For example, introducing too 
much feedback can cause oscillation; its old description (that it di.d 
something useful) must be discarded, and it must be seen as part of the 
problem instead of part of the solution. Its old super task must be marked un- 
/:REDUCEO again, and a new way must be found to solve it. 

> Terminating active subtasks, especially policies, of a rotten task. In 
electronics, constraints derived from circuit diagrams must be removed when an 
IMPROVE task is executed and changes the topology of the circuit diagram. 

The information about what edits are legal must be part of the mistake 
handler. For example, the plans regarding constraint collapse (see Chapter 
III) mu9t specify that the highest task that is the scope of some of the 
collapsed constraints is still healthy; some lower-level task (probably 
associated with a particular canned circuit diagram) must be declared rotten 
and its policies abandoned. 

The reason why th'19 gcheme ha9 not been implemented i9 that it depends on 
the data-dependency machinery I described, which is still relatively untested 
itse)f. Undoubtedly both of these systems will grow together. 

II.F Programmer' s Guide 

A9 I said, NASL is not exactly a programming language, but it's not a 
natural language either, so it is probably best for the programmer to approach 
it first as the kind of formal language he understands best. To help with 
this, I include "programmer's manuals" in each of these three tough chapters. 

NASL has two interpreters — the theorem prover (STP) through which al I 
NASL formulas must pass, and the plan interpreter (NASL proper) which takes 
some conclusions to be instructions to act. The first design decision in 
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expressing a new set of facts in NASL is whether to rely entirely on STP or to 

cast them as rules which create and manipulate tasks. 

In principle, everything could be handled by the theorem prover. For 

example, axioms could be introduced defining a space of electronic circuits, 

and constructively proving 

[EXISTS (X) (AND (ELECTRONIC -CIRCUIT ?X) 
(|P| ?X)H 

could replace the action [DESIGN |P|]. 

As we all know, however, all theorem provers of STP's class rely heavily 
on the generate-and-test problem-solving method. Generating all circuits is 
obviously ridiculous. 

Here are "some more general criteria for deciding whether to represent a 
body of facts as axioms or plans: 

(1) As R. Moore (1975) has pointed out, it is a strong clue that a theorem 
prover is out of place when side effects enter naturally into the statement of 
a body of knowledge; this is certainly true for design. Any irreversible 
action, such as asking a question or wiring a circuit, rules out the use of a 
raw theorem prover. 

(2) If you wish to take advantage of information relevant to a choice 
point, the choice must come up as the choice of a way to do a task or of the 
answer to a /:FIND. (You should verify that the information is worth the 
trouble.) 

(3) If subgoals arise which must interact, you must put the goals in the 
data pool, i.e., make them tasks. Similarly, if you wish to manipulate goals 
as data structures, you must add rephrasing knowledge for tasks of that type. 

Only if it appears that only brute-force deduction is necessary or 

feasible should you cast the knowledge as pure axioms. An example is the 

■theory of frequency-picture manipulations developed in Chapter IV. Commonly a 

class of tasks will be associated with a "mini-theory" of some characteristic 

criterion for choosing between them; this little theory is expressed in terms 

of pure axioms. For example, the theory of ordering the selection of 

component values with respect to other tasks (Chapter III) is a small set of 
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axioms. (The merits of this "clever cogitation directed by brute-force 
retrieval" organization will be discussed in Chapter VI.) 

I I.F.I Predicate-Calculus Techniques 

Even after you have decided to represent a body of knowledge as a set of 
facts about tasks, these facts must be expressed as predicate-calculus 
implications. The approach to this that I have found useful is to think of 
them independently of their use first, concentrating on what they are to mean. 
Once thi9 is done, the pragmatic content can be added. This approach forces 
you to think about what you really mean to express. For example, when you 
write an implication of the form t|P| o (/:TASK ...)], do you really intend 
that this task exist only while P is true? 

There are three pragmatic decisions to make: whether to express 
Implication as /:C0NSEQ, /:ANTEC, or /:GEN; where to use packets; and which 
version (/:-, -, or «/>) of equality to use? 

The first decision is often simple. Systems of predicate-calculus rules 
develop in such a way that one layer of rules "feeds" the next during forward 
and backward deduction. The rules usually work together to record in a 
forward fashion up to a point; then backward (consequent) rules work their way 
from deductive goals to the formulas recorded by forward rules. Generative 
{"-/> G") rules are useful in mixing these processes up. So, for instance, it 
is no use having an antecedent rule if no one records an expression matching 
Its left-hand side. R. floore (1975) has given some useful hints in deciding 
which way implications can be used. 

/:PKT should be used instead of AND on the right-hand side of an /:ANTEC 
when much of the contents of the conjunction are not looked at for most 
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instantiations, or if it is not necessary that they trigger further /:ANTECs 
immediately. This is true, for example, of circuit diagrams, where 
information about the purposes of components is not always accessed: but not 
true of plan schemata, where all the tasks and subtask relations are going to 
be recorded anyway (and the interpreter must notice every task). 

It is usually clear which version of equality to use. Goals are usually 
phrase in terms of "-," but if you know there is only one simple answer, use 
"/:-," which merely matches the two sides against each other. Simple "-" will 
work harder in the case where they don't match. Often "-/>" does not have to 
mentioned in the rules where it it is used; if rules like [»/> ' (F A) Bl are 
around, they will be applied when the right-hand sides of implications like 

t-/> A <P ?X) (Q (F ?X)|] 
are detached with the variables bound. That is, recording [P A] will cause [Q 
Bl to be recorded. 

Finally, remember that it is not always enough to supply axioms about 
proving propositions with a certain predicate? if you ever wish to disprove 
such propositions, you must supply appropriate axioms. Often disproof 
information can be summarized with a single PRESUMABLY statement. For 
example, in the world of blocks, we might have 

[-/> C (AND (ON ?X ?Y) (ABOVE ?Y 71)) (ABOVE ?X 71)1 
t-/> C (ON ?X ?Y) (ABOVE ?X ?Y)] 
[PRESUMABLY • (NOT (ABOVE ?X ?Y) ) CI 

The effort to prove [NOT (ABOVE A B)l will cause (via /: CONSISTENTLY) an 

effort to prove A 1s above B; if it fails, the conclusion is taken as true. 
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II.F.2 NASL Programming Techniques 

In applying NASL to a new problem domain, one must supply model- 
manipulation statements to actually get things done, and indexed plan schemata 
to orchestrate them. 

Tasks may be reduced in a forward or backward way. In the former, the 

presence of a task can trigger deductions of subtasks. For example, in the 

world of blocks, one could specify a plan to the clear the top of a block 

thus: 

[-/> A (/:TASK ?N <> (X (CLEAR ?X)) <>) 

(-/> A (-/> '(/: TASK -STATUS ?N) ACTIVE)) 
(FORALL (Y) 

(-/> A (ON ?Y ?X) 

(S '(EXISTS (T) 

(/:TASK ?T <> 

(X (PUTON ?Y TABLE) ) 
<>) ))) ))] 

(Notice the use of "S" to indicate that these tasks are being triggered, not 

supported, by the statement [-/> '(/: TASK-STATUS | task]) ACTIVE!.) 

In backward reduction, plan schemata are instantiated via /:D0-SUBNET 

calls. This requires a couple of formulas. In the same blocks world, we 

might have the formulas 

(/: TO-DO ?TSK (ACHIEVE ' (ON ?X ?Y)) <> 
(/: DO-SUBNET (ACH-ON ?X ?Y) <>)) 

[-/> A (/: PLAN-INSTANCE ?PI (ACH-ON ?X ?Y) 7SUPER-TASK) 

(AND (/:TASK (CLEARER-1 ?PI) <> (X (CLEAR ?X) ) <>) 
(/:TASK (CLEARER-2 ?PI) <> (X (CLEAR ?Y) ) <>) 
(/:TASK (PUTTER ?PI) <> (X (PUTON ?X ?Y) ) <>) 
(/: SUCCESSOR (CLEARER-1 ?PI) (PUTTER ?PI)) 
(/SUCCESSOR (CLEARER-2 ?PI) (PUTTER ?PI))H 

The interpreter, when it has decided to reduce [ACHIEVE '(ON ...)] using the 

first rule, will create an instance of the schema (ACH-ON ...]; the second 

rule will then trigger the creation of several subtasks. 
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A corpus of NASL rules is often written as an incomplete set of plans and 
axioms, which is then debugged by adding "interaction terms," i.e., knowledge 
which influences the application of the first-order rules. This occurs 
through the medium of these kinds of rules: 

> Rephrasing rules which redescribe actions, usually by breaking them into 
pieces and putting them back together. 

> Choice rules which influence the way in which tasks are reduced. 

> Rules specifying /tSUCCESSOR relations. 

> Policies to watch for interactions between tasks or to influence 
choices. 

Ue Hill see plenty of examples of NASL plans and rules in the following 
chapters. 
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III Design of Hierarchical Systems 

Design is the production of an object to satisfy certain requirements. 

The requirements may describe the desired object closely ("A stick 10 inches 

long"), or they may be very remote from what is finally produced ("Something 

to make this room look more friendly.") 

Of course, designing does not mean actually manufacturing an object; what 

is actually produced is a detailed description of one. In fact, design might 

be described as the process of adding detail to a description until "full 

detail" is reached relative to some basis. 

In what follows, I will elaborate this theory, and then explain how it is 

implemented as a set of NASL rules. (A close relative of this theory was 

outlined by Freeman and Newell (1971) in a paper called "A Model for 

Functional Reasoning in Design.") 

The best way to explain it is to start at the bottom, near the "basis." 

The basis for a design domain is a set of primitive artiTacts. For example, 
if sticks are primitive, designing a stick 19 inches long is merely a matter 

of "instantiating the stick primitive." "Instantiation" means creating a 
symbol, such as X843, and recording that it denotes a stick. That is not all, 

however. Associated with the primitive "stick" are attributes such as its 
length, width, material, color, etc., which must be fixed for a concrete 
instance of it. Because it is a primitive, we may assume that fixing a 
stick's qualities is merely a matter of choosing them. (Wooden sticks are 
cheaper than platinum, but I will not consider cost explicitly in this paper. 
I emphasize finding any solution to a design problem, not finding the best 
solution. ) 

So designing a stick is just a matter of picking a name, a uidth, and a 
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length. (Assuming brown wooden sticks from now on.) If the length is 
constrained to be 18 inches, that is clearly the length to pick. The width, 
if unconstrained, may be picked arbitrarily, subject to the reasonable 
constraint on all sticks that their width be no more than 18* of their length. 

For a primitive artifact, then, "adding detail" is just selecting values 
for its "control attributes," such as length and width. 

This theory of design will not account for the design of "something to 
make a room more friendly," mainly because "object that makes a room look 
friendly" is not a primitive artifact with a fixed set of attributes. In 
general, a requirement may be arbitrarily remote in structure from the kind of 
object that satisfies it. 

So it is necesary to provide for for the Indexing of partial solutions by 
their important features. That is, the theory must just provide for 
statements I ike, 

"Funny posters make a room more friendly." 

"Plants make a room more friendly." 

"If x makes a room more friendly, and y (distinct from x) 

makes a room more friendly, usually the combination of x and 

y makes a room more friendly." 
etc. 

A partial solution of this kind may be a primitive artifact, in which case 
the problem has been solved, but more generally it consists of a structure of 
design subproblems. These subproblems must be solved in much the same way as 
the original problem, and the solutions must be connected up. Eventually the 
original problem will have been completely reduced to primitives. (Fig. 
1 1 1 .11 
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Figure III.l Function-Structure Graph 
These primitives will be connected and constrained. Some of these 
constraints come from the problem (e.g., "Amplifier with gain - 10"), some 
from the partial solution ("A common-emitter's gain is beta X R|_/Rg"), some 
from connections ("The current from R[_ is the current into the collector"), 
and some from descriptions of primitives ("The resistance must be positive"). 
As with the simple stick problem, the control attributes of the primitives 
must all be selected subject to the constraints. 

The design process suggested by Fig. III.l neglects several complications 
having to do with pragmatic knowledge of partial solutions. Some of these 
will be easier to talk about after I introduce the NASL implementation of this 
design theory. Before I do that, I should say more about the "indexing" of 
partial solutions. 
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If a design requirement is very simple, it is is plausible to imagine it 
as calling to mind a partial solution tagged with "specs" which match the 
requirement. For example, the design problem "flake a common-emitter 
amplifier" could plausibly match the specs on the common-emitter circuit 
exactly. 

For more complicated problems, this Mill not work. The description might 
contain conjunctions, disjunctions, or quantifiers. It might consist of 
simple pieces whose solutions can be composed. It may be cluttered with 
numbers which have to be described more suggestively, as in the example of 
Chapter I, in which "gain - 10" was replaced by "moderate gain." Finally, the 
description might just be in the wrong terms: a common example in electronics 
is the translation between time-domain and frequency-domain descriptions of 
signals. 

So the theory must provide for manipulation of problem descriptions, 
before the first partial solution can be proposed. This manipulation is aimed 
at transforming a description Into a form suitable for retrieving stored 
partial solutions. 

A version of this theory has been encoded in NASL. As coded, it is 
independent of electronics, although enough restrictions have been placed on 
it to keep me from claiming it is a complete general design theory. It is 
meant to be a theory of engineering design, for which, to first order, all 
effects can be thought of as local interactions among connected modules, each 
of which is designed to accomplish some part of an overall objective. It is 
biased toward systems whose interactions can be described numerically. I will 
call this domain "design of hierarchical systems." 

It is straightforward to express in NASL most of the concepts I have 
outlined. The first step is to implement the notions of "requirement" and 
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"structure fulfilling it" a9 tasks and subtasks. That \s, a design problem is 
expressed as a task, and the terminal nodes of the function-structure graph 
are to be identified with primitive tasks of the form "grab a (primitive) 
component." For example, a first-pass analysis of an electronics problem may 
generate this structure: 



Acquire 
Stage 1 



O 



o 



Make a cascade 




♦.0 Couple 



O 



Acquire Stage 2 



Figure I II. 2 A Two-Stage Cascade 
Later elaboration will instantiate the coupling task: 
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COUPLE 




Figure I II. 3 An LC-coupled Amplifier 
"Partial solutions" are implemented as a kind of plan schema. A 
particularly important kind of partial solution is a device type, a packet of 
facts clustered around a concept like "amplifier," or "operational amplifier," 
or "resistor." Some of these facts describe the structure of the devices of 
the given type, but many of them are concerned uith how such devices are used 
in solving larger design problems. This last set of facts defines a set of 
tasks for elaborating a device and connecting it to its peers. 

Primitive devices are those uith no internal structure, whose elaboration 
consists mainly of selecting values for their control attributes. The system 
represents these obligations as a set of "SELECT-VALUE" tasks. The 
constraints that accumulate during a design are implemented as policies which 
influence the execution of SELECT-VALUE tasks. 
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Because we are using the NASL interpreter, all design subproblems are 
represented explicitly in the data base as tasks. Partial solution plans are 
recovered, as for all tasks, by using STP to retrieve them. Choice rules are 
used to choose among or compose sets of partial solutions. Simultaneous 
subproblems are represented by simultaneously active tasks. There are 
frequent cases where it is important to start on one problem before another, 
because the solution to the first will Influence the choice of approach to the 
other. This can be arranged by writing rules to cause the deduction of 
/: SUCCESSOR formulas. 

The manipulation of requirement descriptions when routine indexing fails 
to retrieve a partial solution is handled by a special design rephrasing plan. 
It says to turn a recalcitrant design task into a task network of the 
following kind (cf. Fig. 1 1 1. 8): make a device of a known type, and constrain 

it. The plan is to do this by tearing the given problem into piece3 called 

"shards" (usually conjuncts from the design requirement), each of which is 
classified as specifying either the device type or a constraint. The plan 
succeeds only if every shard is accounted for in one of these ways. It is 
generally the responsibility of rules from domain-dependent plans to make sure 
this Is true. In the electronics domain, as we shall see, there are many 
rules for manipulating shards, ranging from those which convert shards 
regarding gain into control -quant i ty constraints, to those which change 
signal -conversion shards from the time domain to the frequency domain. 

This is a broad outline of the design theory encoded in the formal theory 
of DESI. (Appendix 2) A point to notice in its exposition is that I appealed 
to innate control concepts to explain notions of structure, purpose, and 
constraint. It will be seen that appeals like this, appropriately formalized, 
are the only kinds of knowledge of these concepts that DESI has. In a 
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primitive May, the program exhibits "machinomorphi sm, " the inclination to 
understand other systems in terms of its oHn kinds of motives. This allows a 
certain computational economy, and makes assimilation of new information more 
reliable by enforcing a small vocabulary. A complicated and delicate (or 
electronics-dependent) theory of purpose and commitment does not have to be 
added by the user. 

Before turning to a detailed exposition of the OESI implementation. I 
should mention three issues I will have little to say about: learning, search, 
and creativity. The last of these may seem the most important. Many people 
would probably be skeptical about the ability of a machine to do design, 
because creativity seems to be absent from machines and vital to design. 
Indeed, "design" and "creativity" seem almost to be defined in terms of each 
other. If this issue bothers you, let me call your attention to the 
distinction between "routine" and "imaginative" design. Routine design is the 
production of an artifact in a field (such as electronics) such that anyone 
else with an ordinary mastery of the field could have produced the same thing. 
ThiB kind, of design is the only kind I can claim to have a theory of. 

DESI does not learn anything from doing a design. Although at the 
beginning of this chapter I described designing as adding more detail to a 
description, the description at the end of a design is not represented the 
same way as the problem description. The problem description is essentially a 
X-expression, but the final result is a set of statements in the data base 
about "X843," or whatever symbol was chosen to represent the target device. 
To learn, DESI would have to gather these statements together into a new plan, 
and index it under a useful generalization of the problem. Ooing this is 
difficult. (Cf. Sussman, 1975) 

Other kinds of learning are also possible. One can imagine a program 
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learning how to order certain kind9 of subproblems, or how to choose and 
compose partial solution. These are examples of "trial and error" learning; 
to attack them requires a theory of search. 

DESI, like all NASL systems, tries, never to make a choice at random, and 
never backs up to undo a choice. (See the discussions in Chapter II.) Thu9, 
it can be said not to search at all. This is the right organization, but it 
needs to be combined with a learning system that proposes new choice 
principles by watching what happens after it does make an arbitrary choice. 
For example, if one amplifier circuit is chosen from several that satisfy the 
known choice principles, and later its impedance is discovered to be too high, 
the system should not back up, but should make up a new choice principle to 
rule that circuit out in case high impedance is required. 

The system currently does none of these things. If its rules get it into 
trouble, it will look for a correction plan that fits the situation, but will 
do the 9ame thing all over again if the next problem is similar. This is a 
serious, but (I hope) temporaray, defect, in the theory, since it seems clear 
that people learn something new in the course of all but the most routine 
design tasks. 

As I describe in detail DESI's design theory, I will point to the more 
formal exposition of Appendix 2. By looking there, you will be able to judge 
the power of the NASL control language. It will be seen exactly how often it 
is directed and flexible, and how often clumsy, arbitrary, or inextensible. 
The important point at issue during this otherwise tedious exercise is one's 
ability to represent various specialized control and debugging strategies 
U9ing the framework of tasks, data-dependencies, and conflicts described in 
Chapter II. In what follows, references to the formulas of Appendix 2 are 
indicated thus: <*formula-name>. 
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1 1 1. A The Representation of Knowledge about Dev 



ices 



Much of design is the manipulation of devices. A device is any 
manipulate, "physical" object in a design domain. (Thus, signals Mi 1 1 not be 
devices, but nodes will be.) Familiar classes of devices that are useful are 
called device-types. These classes may be formed in several ways. (Sect. 
III.A.l) Each device in a class is described by a set of formulas arranged in 
certain standard ways. (Sect III.A.2) A set of formulas describing a device 
type is instantiated to form a particular device's description. Knowledge 
about a device type is therefore conveniently represented as a "packet" 
(McDermott. 1975) of facts which is instantiated when a particular example is 
considered. This packet is called a device schema. (Unfortunately. Brown and 
Sussman (1974. A. Brown. 1975) have used the term "plan" for this purpose. 
This conflicts with the usual range of meanings of this term in AI. I have 
used this term in the more traditional meaning already in discussing the 
interpreter.) 

III.A.l Hierarchies of Device Types 

Device types which have a recognizable function and circuit diagram (or 
symbol) are called basic. Basic device types may be lumped into loose classee 
called superordlnate device types. <*DEVICE-CLASSES> (This terminology is 
borrowed from (Bobrow and Uinograd, 197S) . but I am not sure I mean the same 
thing by it that they do.) Sometimes such a higher class exists just because 
people have a name for it and use it to specify problems. An example is 
"amplifier." Sometimes there is some class of facts it is convenient to store 
together, as for "2-terminals. " (See Chapter IV.) 
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Kind3 of Device Type 

Basic 

Primitive (e.g., resistor) 

Composite (e.g., common-emitter amplifier) 

General 

Special ized 
Ideal (e.g., current source) 

Superordinate (e.g., amplifier, 2-terminal) 

Figure 1 1 1.4 A Hierarchy of Types of Device Types 

Basic device types may be further classified <*BASIC-DEVICE-CLASSES> as 
primitive, composite, and ideal. Primitive devices are the terminals of a, 
complete function-structure graph. (See belou.) Ideal devices such as current 
and voltage sources behave as primitive devices, but must be "implemented." 

Canned devices that are made up of simpler components are called composite 
device types. Textbook diagrams of things like Hartley oscillators and 
common-emitter amplifiers may be taken as standard examples of composite 
device types. Often these textbook diagrams leave implicit what I take as an 
important feature, that they exist in genera7 and specialized versions. (Fig. 
II 1.4) <*GENERAL-DEFN> The general common-emitter amplifier, for instance, is 
ju9t a transconductance treated in a certain way, whereas the "typical common- 
emitter" has biasing resistors hung all over it. (Cf. Uatson, 1970) This is 
expressed as 

[DERIVED TYPICAL-CE GENERAL-CEJ . 
The importance of this relation will be brought out shortly. 

Thu9 a particular device will be at the bottom of a hierarchy of general 
and superordinate devices. (Fig. 1 1 1. 5) 
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Figure 1 1 1.5 Devices in The Type Hierarchy 
The relation between the devices above the BASIC level in Fig. 1 1 1.5 is tSUB- 
DEV-TYPE |dev type| |superordinate dev type|]. Below that level, the relation 
is tSPEC-DEV-TYPE | specialized dev type| |dev type|J. Thus we would write 
[SUB-DEV-TYPE COntlON-EniTTER AMPLIFIER] and ISPEC-DEV-TYPE TYPICAL-CE COMrlON- 
EMITTERJ. (The DERIVED relation will be explained below. Sect. III. A. 2.) 

A device will be of several device types, written [DEV-TYPE |dev| |type|l. 
There is usually one, its MAIN-DEV-TYPE, which is the most specific category 
it is known to fal I in. 

1 1 1. A. 2 The Representation of Device Diagrams 



A device is either primitive or composite, depending on its main device 
type. A device is specified with several kinds of information (most of them 
are not necessary for primitive and ideal devices): 
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(1) The components of devices of that type. This is kept in formulas of 
the form 

[COMPONENTS |device| < -component names- >] 

Each component is itself a device, Hhose main device type is expressed by a 
separate formula. For example, for a voltage divider VD#21 we might have 

[COMPONENTS VD#21 <(R1 VD#21) (R2 VD#21)>] 
[MAIN-DEV-TYPE (Rl VD021) RESISTOR] 
[rlAIN-DEV-TYPE (R2 VTJ#21) RESISTOR] 



(2) Connections and constraints between components. There can be no 
domain- independent notion of connection between physical objects, since any 
physical medium can be exploited. The only completely general thing that can 
be said is that connecting devices "constrains" them in some uay. 
(Otherwise, there would be no point in connecting them. Cf. "C0NSTRAINT2" in 
Fig. 1 1 1,1.) As we shall see below, there is a rich theory of constraints 
bui It into OESI. 



(3) Control quantities. These are numerical -valued attributes of the 
device that the designer has complete or partial control over. They are 
represented by formulas like 

[CONTROL |attribute| |device| |range| |degree of control |J. 

This declares attribute to be a control attribute; it means that the quantity 
[|attribute| |device|] may be assigned any value from the set of numbers 
range. Since real components often vary from their nominal values, the 
formula specifies the degree of control of the attribute, which is the 
quotient of the highest and lowest possible true values compatible with the 
selected value that appears in the data base. This value is actually the 
(geometric) mean of highest and lowest values. These uncertainties will be 
taken into account in reconciling constraints. As an example, in electronics 
for a transistor Q#173 we might have 

[CONTROL BETA Q#173 (INTERVAL 10 500) 10], 

since the beta of a transistor is controllable only to within an order of 
magni tude; whi le 

[CONTROL POLARITY Q#173 <+l -1> 11, 

since every transistor is unambiguously PNP or NPN. 

A distinction must be made between immediate control quantities and 
derived control quantities, corresponding roughly to attributes of primitive 
and composite devices. There are several relevant formula types for 
expressing information about these matters: 

(a) [IMMEDIATE-CO ' |control quantity!] 

Example: [ I MMEDI ATE-CQ ' (RESISTANCE R02D) 
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(b) tDERIVEO-CQ ' |control quantity|l 

Example: [DERIVEO-CQ ' (V-GAIN AHP#34)] The actual function 
relating the V-GAIN of the amplifier to the values of its components' 
control quantities can be derived from constraints found in the 
description of AMP//34. Often these will be found in the device schema of 
which Af1P#34 is an instance. 

(c) [GENERIC-CA |attribute|l 

Examples [GENERIC-CA THEV-R] It Mould be tedious and wasteful to 
derive a formula for each device or device schema relating its Thevenin 
resistance to its components' values. (A change of topology, for 
instance, would force a recomputat ion. ) Instead, some control attributes 
can be declared generic, meaning the system knows how to compute them and 
will when they are needed. (The current system can handle this to the 
point of enqueue ing a CALCULATE task, but the computational techniques 
required have not been implemented.) 

(4) Task 1nrormat1on. Every device has a cloud of tasks floating around 
it. These will be of various sorts: 

> The purposes of a device and its components are represented by a set 
of finished tasks associated with acquiring them. 

> Many devices will not function as they are supposed to without further 
work ("subrequirements" in Fig. III.l); these active tasks are called 
expansion obligations. These ride along on most composite devices and even 
some primitive ones; a transistor, for example, must be biased into its 
intended mode. 

> A device carries along monitors on the topology of the connections 
inside it and from it to other devices; some of these monitors are for 
protection of important relationships, and some just to notice when something 
must be recomputed. 

These are characteristics of devices. A device schema is merely a canned 
set of such formulas with a free variable to be bound to a particular device 
when it is made. Device schemata are used to represent device types. They 
are usually implemented as "packets." (McDermott, 1975) For example, the 
packet for "voltage divider" will include the formula 

(COMPONENTS ?##VD <(R1 ?##VD) (R2 ?##VD)>] 
from which the formula given above for VD#21 will be derived. The prefix 
"?##" specifies that ?##VD is a variable loosely bound to an "abstract voltage 
divider." The formula says, "the typical VD ?X has components [Rl ?X] and [R2 
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?Xl. n ) 

The tasks that wi II be liberated when a device schema is instantiated are 
called Frozen tasks, and the liberation process is called "thauing." Frozen 
tasks may be thought of as mummified remnants of actions that were 
(conceptually) executed when the device schema was first put together.. 
(Device schemata are to be thought of as the result of previous designing 
activity followed by summarizing what was learned, but this is just to help 
your imagination; such a learning scheme doesn't exist yet.) One thing that 
must be left around in a schema is a record of why the various components were 
acquired and connected as they are now found; in other words, the purposes of 
the components. (If for no other reason, these are necessary in case they 
have to be undone during mistake correction.) 

The simplest uay to accomplish this is to keep the tasks that were known 
at the end of the (imagined) design episode in a frozen state. Some of these 
will have been FINISHED; for example, the tasks that acquired the components 
are there just to record why they were acquired. Others are still active. 
For example, there will be ACTIVE constraints and protected model 
manipulations. 

By way of illustration, a voltage divider may be first thought of as a way 
of setting a bias voltage in a particular amplifier design problem. A voltage 
divider found in a schema must be associated with a policy of keeping that 
bias voltage set. 

An advantage of the frozen policy solution compared to a more specialized 
implementation of purpose comments is that one mechanism is used to handle 
local cooperation and conflict of tasks as well as interactions of new actions 
with old purposes. This is an example of the "machinomorphism" I mentioned at 
the beginning of this chapter. 
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Specialized device types are arranged in a hierarchy according to the 
DERIVED relation. This is a more complex relation than SUB-DEV-TYPE and SPEC- 
DEV-TYPE (cf. Fig. III. 5), which are used mainly to cause properties of higher 
types to be inherited by lower. <*SUB-DEV-TYPE-1 . SPEC-0EV-TYPE-1> Most of 
the properties of a general circuit, such as its topology and components, ar.e 
not to be inherited by its specializations. However, there is an important 
class of properties which must be accessible from the specialization: the 
frozen tasks of its more general counterpart. The relation between a general 
circuit and its specialization is precisely that the expansion obligations of 
the general circuit are fulfilled by the structure of the specialization. 

To represent this relation, we need some more equipment. Every device 
thawed from a schema has a "deep freeze" of frozen tasks, which are collected 
for convenience as the subtasks of an abstract task called the [DEEP-FREEZE 
|device|l. If dev-type 1 is derived from dev-type 2, then a device of type 1 
will have a "SOUL" which is a device of type 2. <*S0UL-0N-ICE> The important 
relation between them is that every subtask of the soul's deep-freeze is to be 
a subtask of the original device's deep-freeze. This inheritance is done via 
/iCONSEQ deduction, since it is not important to see every frozen task during 
normal operation; most of them will have been reduced anyway. They are mainly 
valuable in explaining the purposes of components. 

For many examples of device schemata, see Appendix 3. 
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III.B Design Actions and Plan9 

I can go no further in talking about devices without talking about design 
actions. This is because devices' purposes are so intimately associated with 
the purposes of their designer, in this case DESI; and DESI's purposes are 
expressed as tasks. 

Design actions fall naturally into these classes (see Fig. III.B): 

(1) "Design something with property p": Starting with no structure or hint 
of it, one i9 to produce such a thing. 

(2) "flake an x": Here x is a device type, an example of which is to be 
created. This kind of action breaks down into subtypes, depending on what 
kind of device type x is. Making a basic type tend9 to be a matter of 
choosing which version along the specialization scale to use, then plugging in 
its frozen tasks. Making a superordinate type requires more involved and 
careful choice, since the 9ub-types to choose from usually have incompatible 
properties. 

(3) "Constrain something": Things that can be constrained are not devices, 
but quantities. There are two classes: physical quantities such as voltages 
and currents; and the control quantities, such as resistances and power gains, 
that I described above. 

(4) "Change a device": Given a structure, it can be altered in various 
ways. These actions include fixing a physical quantity, biasing a circuit, 
adding feedback to improve stability, and coupling two stages. The actions 
are defined by plan schemata that often come in specialization hierarchies 
like those of devices. A major subdivision of these are actions uhich involve 
changing the previously reigning plan network as well, for example, altering a 
control quantity which is already fixed by constraints. 

This list is derived by common sense, and from perusal of 100 Ideas for 

Design (Electronic Design, 1964) , among other works. (Senturia and Wedlock, 

1975) 
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design Actions 

1 DESIGN 

2 MAKE 

superordinate 

primitive 

ideal 

general 

specialized 

3 Constrain 

CONSTRAIN 
SELECT-VALUE 

4 Change 

FIX quant i ty 
BIAS 
COUPLE 
Patch 

IMPROVE gain, input-Z, selectivity,... 

Figure 1 1 1.6 Design Action Taxonomy 

The design problems which appear in books such as these include 

"Design a power amplifier..." (Type 2) 

"Increase the current..." (Type 4) 

"Isolate two connected devices" (Type 4) 

"flake the quiescent output voltage 48V" (Type 3) 

"Design a circuit with a high gain-bandwidth product" (Type 1) 

"Avoid loading" (Type 3) 

(There are other kinds of actions, such as "simplify a circuit," which I have 

not counted as among these types. I hope they can be added, but I have no 

plans to do so.) 

II I.B.I DESIGN 



There is only one action in this class. 

[DESIGN | prop | 1 — > [<|namej>] 

This action usually arises at the top level. Successful execution of such 
an action creates a model of a device that has property prop. In easy cases. 
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Figure 1 1 1. 7 Design Rephrasing Plan Schema 
This is a plan to manipulate the design problem as an object. 



The plan 



network is set up using a formula <*+DESI-l> uhich extracts the desired 
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predicate a9 the value of ?+P. In this context, the embedded formulas, 
prefixed with the character "_", are being used essentially as SNOBOL patterns 
(Farber et. al., 1964) to tear the goal to be rephrased into manageable 
pieces. So ?+P will have value t[|prop|]]. (See Appendix 1.) 

Remember that the final aim of a rephrasing task is a revealing reduction 
of it9 target task. A detailed analysis of the problem may be postponed; the 
important thing in rephrasing is to make it "familiar." The goal in the case 
of the design rephrasing plan is to reduce the design problem to the following 
net: 



D-NOTE 



o 



policies on r\ 
MAKE ^Q 




side -tasks 

(usually CONSTRAINS) 



Figure 1 1 1. 8 Rephrased Design 

The strategy of the designer is to "explode" the given predicate into "d- 
shards," which are conjuncts of the original predicate. Discovering d-shards 
is occasionally straightforward <*D-SHARD>, but usually depends upon formulas 
for the domain involved. (See Chapter IV.) 

The d-shards are valuable only insofar as they lead to one of three 
things: 

(1) A core -device -type the MAKing of which is the simple first step of the 
rephrased design plan (Fig. 1 1 1. 8); 

(2) Side-tasks, typically to enforce numerical constraints discovered as 
d-shards; 

(3) D-features, qualitative predicates U9ed as policies in making a core- 
device-type. 

This fact is expressed as the policy task ACCOUNT-FOR-ALL, which says to 
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make sure that every d-shard leads to one of these three things. In the 
current implementation, it is an error if a miscreant shard is discovered. A 
mdre sophisticated implementation would know how to try harder and attempt to 
learn from its efforts. 

The only other feature of interest in the general design rephrasing plan 
is the step CORE-FINDER, during which NASL must find the core device-type to 
be used. The core device type is often clear from a d-shard of the form t IX 
i\v\) (DEV-TYPE ?M |dev-type|)]] <*C0RE-DT-1>. However, rules from 
particular domains can and do suggest device-types based on more elaborate d- 
shard processing. The interpreter must choose one. It is the responsibility 
of the writer of this knowledge to provide choice rules to get out of this 
situation. However, there is one rule <*C0RE-DT -CHOOSE > which is domain- 
independent: if one device type is subordinate to another, reject it. (It 
should be suggested later anyway by the policies that grow out of d-features.) 

This rephrasing method may be compared with the proposal of Moore and 
Newell (1974) for the MERLIN program. The idea there was to be able to "view" 
any conceptual structure as another by a process of mapping the pieces of one 
into the pieces of the other. DESI tries to view any design problem as 

"making a ..., while noticing hints +++., then doing "; this template may be 

seen as a three-slotted structure, such that every piece ("d-shard") of a 
design problem goes into one of these slots. The process is more structured 
than MERLIN; in particular, this kind of rephrasing is not an operation which 
can always be done by def ini t ion; it is capable of failing. The analogy may, 
however, be revealing. (It was suggested by Marvin Minsky.) I suspect that 
many rephrasing problems can be put in this paradigm form, and that the 
rephrasing protocol can be made more specific. However, currently DESI does 
things with rephrasing which cannot be seen as an instance of this paradigm. 
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(An example is equation solving.) 
III.B.2 Making Things 

(1) [MAKE | device type|] »-> [<|name|>] 

The intent of this action is to create ("buy") a device of the indicated 
type. If the device type is basic <*PIAKE-BASIC-PLAN>, a task net is set up 
with a primitive GRABBA action, which will just generate a new symbol and make 
its main-dev-type be the basic type. Extra tasks are hung on the network, 
depending on whether the device is primitive <*MAKE-PRIM>, composite <*MAKE- 
COMPOSITE>, or ideal <*MAKE-IDEAl>. In the case of primitive devices, the 
only commitment enqueued is to select the values of its control quantities. 
In the case of composite devices, the plan subnetwork includes a subtask to 
expand the device at some time in the future. Ideal devices receive a 
commitment to be implemented. (These new tasks are not marked /:MAIN in their 
task networks, so they do not have to be finished before the successors of 
their supertasks are begun; hence, they amount to future commitments.) 

Expansion of a composite circuit means wiring up a circuit diagram for it. 
Usually this just means selecting a specialized device type and declaring the 
circuit to be that type; this is called "specializing" the circuit. 
<*SPECIALIZE-DEFN> The system has a choice of circuit diagrams from the 
specialization hierarchy. If one circuit is DERIVED from another (and hence 
is "specialized"; see Figs. III. 4 and III. 5), it will do the same task, but 
may depend on more specialized assumptions. It is the user's job to write 
rules that suggest circuit versions to match requirements, but the system 
knows about two peculiar specializations of a circuit: its "most general" 
specialization and its default specialization. <*MOST-GENERAL-DEFN, DEFAULT- 
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SPEC-OEFN> If either of these is available, it will be suggested. Generally, 
only one specialized device type of some basic type will come up in a given 
context. The user must make sure that good choice rules are available when 
more than one appears. The trade-offs should be clear: a general schema 
involves more work on expansion-obligations, but using a specialized version 
runs the risk of having to correct the circuit topology when some assumption 
proves unjust i f ied. 

If the user's rules do not sufficiently disambiguate, the system uses the 
two rules <*SPEC-OEV-BETTER, TU0-SPEC-0EVS-U0RSE-THAN-0NE>. The first 
encourages the use of a more specialized device type if it has been suggested: 
the second overrides this one by ruling out conflicting suggested 
special izations. 

Basic device types are just canned diagrams; the choice is which version 
of essentially the same circuit to take. That is why these special cases can 
be distinguished. In choosing among superordinate devices, rules for zeroing 
in on basic sub-type3 are entirely up to the user. 

(2) [ACQUIRE | device type|) — > [<|name|>] 

HAKE a device type, unless there is already one around which can be used. 
<*ACQUIRE-D0-1, ACQUIRE-D0-2> For example, you should always re-use old 
voltage sources instead of making a new one; you should never re-use a 
transistor; and you should look around to see if you can bum a node before 
making a new one. (This last information is purely domain-dependent. See 
Appendix 3.) 
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(3) [EXPAND |device|] 

This action is required for devices which are not fully specified by their 
circuit diagrams. (See below, Sect. I II. A. 2.) This task doesn't require 
elaboration, but accumulates subtasks by deduction. For example, it picks up 
expansion obligations from composite device schemata. These are actions which 
become subtasks of the task of EXPANOing each instance of the device. 
<*EXPANSION-OBLS-DO> Other tasks that are created involve finding all GENERIC- 
CA's of the device that have been constrained and deriving the formulas which 
define them. <*GENER!C-CAS-DO> (See Sect. IV. B. 4.) 

(4) [CONFIG < -types- > 

(A (-vars-) < -actions- > )) 

This is a "macro-action" which is an abbreviation for "ACQUIRE the types, 
then bind the vars to the resulting devices to generate a list of actions to 
perform." <*CONFIG-DEFN> The LISP program SET-UP-CONFIG which elaborates it is 
not shown in Appendix 2. CONFIG is used as an abbreviation in Appendix 3. 

III.B.3 Constraints 

(1) [CONSTRAIN < -quantities- > |pred|l 

Executing this action commits the interpreter to making pred hold true of 
the various physical quantities and control quantities. Thus, it is naturally 
a policy. CONSTRAIN is a peculiar mixture of ACHIEVE and ASSUME. If a 
quantity is under control, you are permitted to ASSUME it ha9 any value that 
doesn't contradict what is already known about it. So, when CONSTRAINing, it 
is often permissible to record any equalities deducible immediately from its 
constraint plus other constraints and equalities to be found in the data base. 
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(Cf. (Sussman and Stallman, 1975).) If these constraints and equalities 
contradict the new constraint, the action fails. (See Sect. III.B.) 

In detail <*C0NSTRAIN-D0>, this is how CONSTRAINing is done: if the number 
of unknowns is exactly one, and the main connective of the constraining 
predicate is "-," then the system is to try to solve the equation 
immediately. <*CONSTRAINT-RESOLVE-DO> If it is solvable, the result is to be 
protected. (See below.) In either case, the CONSTRAIN remains an established 
policy (a "constraint"). 

Algebraic Symbol Manipulation 

Several times in discussions of constraint and equality manipulation I 
have assumed some sophisticated symbol-manipulation ability by the program. 
The various task9 that I take for granted include solving equations, choosing 
values to satisfy rather arbitrary constraints (including inequalities), and 
finding the precise way that a one control quantity depends on the variation 
in another (see Sect. III.B). In the long run, it would be enlightening to 
see whether the structure of the NASL system is sufficiently flexible for this 
information to be encoded as a set of NASL formulas. Preliminary indications 
are that this is quite feasible; very simple equations are already solved by 
the tasks generated by <*EQN-S0LVE-D0>. (Other equations might be handled by 
the methods of (Bundy, 1975).) My judgment has been that to explore this byway 
in more depth would bog me down. This decision is not obvious; after all. 
flexibility of application is one of the main design goals of my system. 
However, having an implementation of one domain is, for now, much preferable 
to having curious fragments of several. Therefore, I depend upon calls to an 
expert symbol -manipulation system to do this work for DESK I might have used 
some symbol-manipulation system like MACSYMA (Math lab, 1974), but. for 
simplicity, I chose myself as this expert subsystem. Whenever a non- trivial 
symbol-manipulation problem needs solving, the system types out a request for 
a solution and waits for its human interlocutor to supply it. 

It is to be hoped that this is not a permanent trend in computer science, 
since it tends to reverse the usual practice of having humans do the creative 
work while machines do the tedious chores. 
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(2) tSELECT-VALUE (control attributel (primitive device|J 

This action is to be postponed until all tasks of Types 1, 2 and 4 are 
finished. <*SELECT-POSTPONE> DESI makes all SELECT-VALUEs subtasks of a task 
SELECT-Ett-ALL which is a successor of every "topology-changing task." It is 
assumed that this kind of task is recognizable from its action function. 
(MAKE and FIX (-quantity) are the only built-in topology-changers.) 

Uhen the system gets to a SELECT-VALUE task, either the control attribute 
for this device already has a value; or DESI must pick a value within the 
range of the control attribute which fits all the known constraints on it 
<*SELECT-VALUE-DO>, and impose model effect 

[-/> M|control attributel jprimi tive device|) |value|l. 
It then PROTECTS the fact that the value satisfies the constraints. 

If there is no such value, the system is faced with a "constraint 
collapse" (see Sect. III.B); that is, it has made a mistake. 

Executing SELECT-VALUE tasks causes the resolution of all remaining 
constraints of a network. 

(3) [PROTECT ' (proposition!! 

The intent of this action is that the system should become alarmed, i.e., 
realize it has made a mistake, when the fact is no longer true in the model. 
This is not as easy as it sounds or as it is usually implemented (Sussman, 
1975), because the given fact may be only indirectly related to atomic facts. 

Because data dependencies are maintained by the system, it might be 
possible in principle to make this a built-in action. That is, the system 
could just wait for propagating erasures to wipe out a fact. Something 
special would have to be done for the results of non-monotonic inference (that 
is, using /: CONSISTENTLY) , because in this case it is recording a fact that 
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could upset the protected fact. 

For this reason (and for the Heak introspective reason that protection 
does not seem to be a fool-proof operation), I have DESI treat protection as a 
problematic action to be reduced to different subtasks in different cases. 
This decision is under review. 

In the design domain, we have need primarily of protecting values which 
are derived from consideration of constraints. This is done <*QVAL-PROTECT> 
by /:t10NIT0Ring the fact that the quantity has a value and /rCONTINUing the 
protection policy when the value is removed. <*PROTECT-CONTINUE> 
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Figure I II. 9 Quantity-Value Protection Plan Schema 
Notice that the variable may be getting a new value which satisfies the 
constraints, so the system cannot jump to the conclusion that a protection 
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violation has occurred. The decision to continue the policy is generally 
postponed. Upon continuing it, if a violation has occurred, DESI realizes its 
mistake. 

III.B.4 Changing Devices 

This is a catch-all category which includes biasing, feedback, coupling, 
and fixing the value of a physical quantity. These actions are described in 
the next chapter. Other domains would have other actions. 

The last action in this list is the only one I feel there is anything to 
be said about at the rarefied level of general design. Even for that one, 
about all that can be said is that, for almost any domain, there exist way3 of 
fixing physical quantities, bringing them under control, creating "boundary 
conditions." For electronics, this is done with sources, voltage dividers, 
etc. In mechanical engineering, it might include fastening things down, 
hooking up motors, etc. Perhaps it is worth saying that "FIXing a physical 
quantity means turning it into a control quantity," but I'm not sure how to 
say that. It is likely that the way one's knowledge of this sort of 
regularity is used is in assimilating a neu domain; namely, everyone knows 
that when he is learning about meta-hydraul ic engineering he should be sure to 
ask what methods there are for fixing meta-hydraul ic quantities. 

Besides these actions, which arise in the course of normal problem 
solving, there are actions (subsumed under "patch" in Fig. 1 1 1. 6) required to 
change a circuit because it is failing to meet its specifications. These are 
described in Sect. III.D; they are not implemented, because the mistake- 
correction machinery to support them does not exist. 

Many design plan schemata are arranged in specialization hierarchies 
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similar to hierarchies of specialized composite device types. (Sect. 1 1 1. A) 
This is especially true of the circuit-alteration plans discussed in the next 
chapter. The reason for this is that a circuit-alteration plan for an action 
like "bias ..." is close to being a device type. The difference is that the 
procedural component is larger and the plan is more anonymous; the resistors 
used for biasing do not become components of a "biasing device." but of the 
circuit that is being biased. 

Just as devices may be related by the predicate SPEC-DEV-TYPE, plan 
schemata may be related by 

[SPEC-SCHEMA |plan schema 1| |plan schema 2|). 
Any instance of the specialized schema (1) is an instance of the general 
schema (2). <*SPEC-SCHEriA-DEFN> Choice rules are provided for these plan 
schemata which are completely analogous to the rules (Sect. III.B.2) for 
choosing among specialized device types. <*SPEC-IS-BETTER, TUO-SPECS-UORSE- 
THAN-ONE> 

Two other useful control predicates defined in the file DESI are STASK 
<*STASK-DEFN> and REDUCE. <*REDUCE-DEFN> The first is used to abbreviate in 
the common case where a task is defined, and made a subtask of something else, 
in the same breath. The second is used to express a common interaction among 
design plans: when one plan accomplishes part of the function of another. In 
that case, saying [REDUCE < -reducers- > |reducee|] means "the reducer tasks 
are all the subtasks of the reducee task; don't bother to try to execute it 
any further." (Cf. Sect. M.B.I.) 
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III.C Composition of Partial Solutions 

One of the most interesting and complex events that can happen during the 
career of any problem solver is the failure of the labels attached to its 
canned plans to match all of the requirements of some task. In a design task, 
this situation allows unlimited scope for the study of creativity. Of course, 
our knowledge of such matters is as yet very slight, so that the approach my 
system takes to the handling of such problems is not terribly brilliant. 

Uhen a DESIGN task does not immediately succeed, an attempt is made (Sect. 
III.B) to break it down into a core task plus several constraints and 
"features." For example, the knowledge in ZORCH is sufficient to discover 
that an amplifier is required given a wide range of requests for designs. 
Then further choice information from ZORCH is used to select one that is 
likely to meet all the amplifier constraints so generated. As mentioned in 
Sect. II. A, this sequence is called the "recognition protocol." Finally, the 
constraints are resolved. 

Often this approach fails. It may fail in more than one way: 

(1) More than one "core device-type" (see Sect. 1 1 1. A) may be discovered. 

(2) There may be more than one way to implement a core device type. (See 
above, especially the discussions of "superordinate" device classes and 
abstract device-types.) 

(3) The constraints generated may not actually be satisfiable. 

All of these problems may call for composition of solutions to subproblems. 
The last problem is peculiar in some ways; I devote section 1 1 1. D to 
describing constraint resolution. 

The others are related by having to do with the choice protocol. For 
example, problem (2) may arise if more than one amplifier fits some of the 
requirements, and none fits well enough to exclude the others. In this case, 
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the response of the system when no further exclusions can be made is to record 
[QUIESCENCE |choice name|] in the choice data pool. 

It is here that choice rules with conclusions of the form [/:RULE- 
T0GETHER...1 are important. They allow options to be superseded by new 
options. Th'19 is the most natural and painless place for composition to occur 
in a NASL-based system. 

This is the closest DESI comes to a universal composition method. This is 
a defect in the system as it exists. A better system would recognize the need 
for a /: RULE-TOGETHER and propose one; future episodes would exercise and 
modify it. For example, some of the choice rules for amplifiers discussed in 
the next chapter contain almost-general principles regarding cascading a 
buffer amplifier to another amplifier when the first was picked for its input 
impedance. It is not hard to see a more general principle regarding inputs 
and outputs lurking behind this specific one. It lurks there still. 

For now, you must be content with the specialized composition rules in 
Chapter IV. 

III.D Constraint Collapse 

As a design proceeds, the current data pool fills up with formulas 
speci fying components, connections, quant i ty values, and constraints. If 
everything proceeds smoothly, eventually there will be a value for every 
primitive component and the problem will be 9olved. The most common thing to 
go wrong with this scenario is to discover that some subset of constraints 
cannot be satisfied. DESI counts this as a mistake in the sense of Sect. 
I I.E. All its previous machinations were based on the assumption that the 
functional requirements could be reduced to constraints and satisfied. When 
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this turns out not to be the case, the task network must be altered to reflect 
what it should have been doing. On the other hand, as much as possible of the 
network must be salvaged. 

As I pointed out in Sect. II. E, my theory of mistakes is as yet poorly 
developed. This section must be taken as a continuation of the detailed 
proposal I made there, not as a description of existing program. 

As a concrete example, say that a low-pass filter is required, which 
filters out one radio station at 788KHz to leave the signal of another, 
equally strong station at 500kHz. 
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Figure 1 1 1. 10 Radio Spectrum With Two Stations 
This problem can be represented easily using the "frequency picture" language 
I will develop in Chapter IV. I will continue to use simple English in what 
fol lows. 

The chosen solution is an RC low-pass filter, an instance of the schema 
represented by Fig. I.G. This schema and the frequency-domain methods used to 
find it (Sect I V.B.I) generate these constraints and equalities: 
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C0N1 (from rephrasing of the problem): 

V O (780 kHz) < .1V (508kHz) 

C0N2 (from schema for RC filter or by analysis): 

His) - l 

1+RCs 

C0N3 (from knowledge of filters): 

selectivity^, f 2 ) - IHCjZnr^l | 

|H(j2nf 2 | 

CQN4 (from knowledge of linear devices): 

|H(j2nf)| - V f) 
V f (f) 

Figure 1 11.11 Relevant Constraints 
From these constraints and the statement of the problem, we can build up 
the following "constraint network": 
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Figure 1 1 1. 12 Constraint Network 
(Cf. <«CQ-CL0> in Appendix 2.) 

If all the constraints are satisfiable, that is, if the output amplitude 
ratio can be made small enough that the second station has negligible output 
compared to the first, everything is fine. But, as it happens, there are no 
values of R and C which can be picked in order to bring this off. This is 
referred to as "constraint collapse." This will be noticed when one of the 
constraints proves unsat i sf iable. Uhich constraint it will be is 
unpredictable; the problem is clearly a problem of the whole network rather 
than any task. 

Recall from Sect. II. E that fixing a mistake involves altering the current 
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world model and the task network. In this case, there are several current 
tasks that have caused the problem: the choice of an RC circuit to implement 
the low-pass filter, and the various CONSTRAINS, some thawed from the RC 
schema, which led to the trouble. DESI has a record of every choice it made 
in the process of setting this network up, so it could find a choice point 
that would make a difference, restore the state of the world at that point, 
and try something else; I have already discussed and rejected this in Chapter 
II. 

The design knowledge of DESI provides us with a better method of solving 
this problem. This method amounts to the following English summary: 

(1) Find a control -quantity in the collapsed task network such that 
changing it would get rid of the problem. This is not as easy as it sounds. 
It is counterproductive to consider "making V (580kHz) larger." for instance. 
Any method for doing that will probably make V (780kHz) larger as well. In 
the example, the proper answer is "selectvi ty. " I assume symbol manipulation 
powerful enough to handle this. (Sect. 1 1 LB. 3) 

(2) Introduce a new task [IMPROVE *| losing control quantity! (direction 
and magnitude!). A task of type IMPROVE, unlike previous control -quant i ty 
manipulators, has the aim of changing some already-set object rather than 
fixing one that has yet to be set. To execute the IMPROVE task requires some 
domain-dependent rephrasing, choice, etc., which by now are routine. By one 
route or another, a plan like that of Fig. 1.7 is recovered. 

(3) The actual tasks associated with the IMPROVE plan perform the 
acquisition and insertion of the new pieces, an amplifier, capacitor, and 
resistor, and the renaming of the output port. The resulting change in 
topology flushes the old constraints on the system function and hence the 
selectivity of the device and enables the design to be completed. This is not 
too painful, since the control -quant i ty t(H ?DEV) ?F] is marked GENERIC-CA in 
the data pool; when the old stored value is flushed, a task is enqueued to 
recalculate it. 

Except for the initial symbol manipulation, this seems fairly simple; the 
IMPROVE task is no different from any other task, such as BIAS or COUPLE, 
which alters the topology and part names of a circuit. The difference, of 
course, is that the policies associated with the IMPROVE plan must specify 
exactly what parts of the old task network encircling the RC filter are to be 
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preserved. The difficulty of implementing this scheme revolve around the 
careful undoing of protections and other policies. 

III.E Programmer's Guide 

DESI is a skeletal theory of design within which the user's domain- 
dependent rules operate. These rules will fall into three classes: rephrasing 
rules, device definitions, and device-choice rules. 

The user's rephrasing rules can be very 9'imple. Any declaration that a 
function is a CONTROL-ATTRIBUTE will cause the cq-shard machinery to turn a d- 
shard of the form UA (X) (- (|attribute| ?X) |value|)]) into a side-task to 
CONSTRAIN the given control quantity. 

More complicated rules can create entire inferential subtasks to make 
finer discriminations. Examples will be given in the next chapter. 

In making up device schemata, the user will have to use his intuitions. 
Superordinate device types are convenient slots to put inheritable 
characteristics Into. A basic device type is one with a "diagram" common to 
every member of the type. (I assume that every domain DESI is likely to be 
applied to will have the concept of diagram.) The "diagram" (device schema) 
will not be attached to the basic device type directly; instead, each node in 
the DERIVED tree below the basic type (see Fig. 1 1 1. 5) will have its own 
schema. (Remember that the details of the diagrams for a device type and one 
of its specializations are likely to be inconsistent; the task networks of the 
two will be related via the SOUL device.) 

In writing choice rules, the user has a certain amount of freedom. There 
are three stages in picking a device type or design plan: deducing 
possibilities, running choice rules before QUIESCENCE, and running choice 
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rules after QUIESCENCE. (See Sect. I I.C.I.) There is as yet no iron-clad 
semantics for what each of these stages means, mainly because I lack 
experience in interfacing rules. 

Typically, the "possibility" rules are very lax; if a device could be 
appropriate, given some piece of the current situation, some rule should 
suggest it. Throwing it away or incorporating it into a larger structure is 
the job of the choice rules. <Cf. CH00SE-AI1P, in Appendix 3, described in the 
next chapter.) 

The user should be careful in his use of /:RULE-0UTs if this is the 
structure he chooses. If there are two relevant variables in a situation, and 
one is, strictly speaking, incompatible with a suggested device or plan, th'13 
is not necessarily a reason to rule it out. After all, it would not be a 
living option in the choice protocol if the other variable had not caused it 
to be suggested. For example, input- impedance considerations may suggest a 
common-collector amplifier, while gain considerations suggest something else. 
It is clearly silly to throw away the common-collector suggestion on the basis 
of gain. Instead, a /: RULE-TOGETHER is probably appropriate. 

/xRULE-OUTs are useful mainly as a device for expressing "differential 
diagnosis" information. Such a rule mentions two or more options, and throws 
one of them away. Remember that the order of examination of these predicates 
is /:RULE-OUT, then /:RULE-IN, then /: RULE -TOGETHER, and that the choice 
protocol quits as soon as fewer than two options remain. 

QUIESCENCE has no fixed meaning. Sometimes the system uses it to express 
rules which are intended to take over if the user's rules can't make up their 
minds; this is the case with the rules for choosing among SPEC-DEV-TYPEs. 
(Sect. III.B.2.) This freedom probably represents a deficiency in the choice 
machinery. 
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IV Electronics 

Electronics knowledge falls naturally into three categories: the physic9 
and mathematics of electronic components, devices, and signals; the knowledge 
necessary to do design, including rephrasing, composition, and patching; and a 
catalogue of circuit diagrams and plans. 

In this chapter as in the last, the notation <*rormuTa-name> is a 
reference to a formula in the appendices, in this case usually Appendix 3. 
This Appendix is rather long, but has been laid out in an order which 
corresponds as closely as possible with the presentation of this chapter. 
This chapter is fairly dull. Given the vocabulary and conventions developed 
in Chapter III, it is routine to encode much of the information I wi I I 
describe. 

Appendix 3, long as it is, can only be described as "sketchy." For each 
important concept I wi 1 1 discuss, there is a representative circuit, plan, or 
rule set in the appendix, but often several of its siblings will be missing. 
I will describe these gaps in Sect. IV. D. 

IV. A Physics 

IV. A. 1 Connections and Constraints on Components 

Recall from Chapter III that connections in a design domain are physical 
configurations associated with constraints. In electronics, these 
configurations are called nodes. 

Interfaces between electronic devices are of two types: terminals and 
ports. I will di9cu9s port9 later. A terminal is a wire coming out of a 
primitive or composite device. A group of terminals may be bunched into a 
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"node." One constraint on a node is "Kirchhoff's Current Lau" (KCL) (Senturia 
and Wedlock, 1975), which says that the sum of the currents into a physical 
node is zero. My "logical" nodes are treated as terminals themselves at a 
"higher level," where they may themselves be joined into nodes. <*NODE-TRMIN> 
(See Fig. IV. 1).) KCL for nodes therefore states that the current into the 
node, considered as a terminal, equals the sum of the currents out of the sub- 
terminals defining the node. <*KCL-2> 





Figure IV.l Terminals and Nodes 
Devices also satisfy Kirchhoff's Current Law. <*KCL-1> A composite device's 
terminals are almost always nodes themselves. These will be declared with the 
predicate DEV-TERMINALS. <*KCL-3> (Fig. IV. 2) 



IV Electronics 130 




(DEV -TERMINALS D* 
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Figure IV. 2 Composite Device Terminals 
A fundamental model manipulation in the electronics domain is to merge two 
nodes, uhich makes them equal. <*N0DES-I1ERGE-MANIP> A less easily visualized 
operation is DEV-INSERT <*DEV-INSERT-f1ANIP>, which breaks a node in tuo. 
(Fig. IV. 3) 




(DEV-INSERT D" N 
<(#1 D")><T2 T3 T4> 
<(#3 D")>< T1 T5>) 




Figure IV. 3 Inserting a Device into a Node 
Ports are pairs of terminals (which are almost always nodes of composite 
devices), to be thought of as carrying signals. The signals may be 
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implemented either as currents or voltages. <*P0RT-TAX0N0MY> A set of voltage 
ports may be grouped into a nest, which is exactly analogous to a node formed 
by grouping terminals. (In particular, every nest is considered a higher- 
level port.) <*NEST-P0RT> Ports may be combined into nests, and nests may be 
merged, just as terminals are combined into nodes. <*NESTS-MERGE-f1ANIP> 

Nest 



Port 




port 2 



(a) 



Figure IV. 4 Ports and Nests 




Kirchhoff also had a voltage law, which for our purposes merely amounts to 
the fact that every point in space can be assigned a conventional voltage. To 
enforce this, the rule <*KVL-1> constrains all the node and terminal voltages 
at a physical node to be the same. 

All devices are given interface descriptions by the packets defining their 
device types. The interface description (e.g., «?X is a 2-terminal") interact 
with formulations of Kirchhoffs voltage and current laws to generate standard 
constraints. <*2-TERMINAL-DEFN> Composite device types (see Chapter III) may 
have terminal or port interfaces, or both. 

An important class of devices are the "signal transmogr i f iers" or SIG- 
TRANSERS, by which I mean any device one of whose primary functions is to take 
a signal in on its input port, or "INPORT," and put out a signal on its output 
port, or "OUTPORT." <*SIG-TRANSER-GL0RIA-r1UNDI> 
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(Much of the notation in this and the following section has been 
influenced by the notations devised by A. Brown (1975) and Stallman and 
Su9sman (1976).) 



IV. A. 2 Signals 

Signals are abstract objects with three components: a time function, a 
signal-medium (voltage or current), and a "home" (a port). "A signal is any 
physical variable whose magnitude or variation with time contains 
Information. .. . Uhen we speak of 'signals,'... we refer ... . to voltages and 
currents." (Senturia and Ued lock, 1975, p. 2) 

A "homeless" signal is not allowed in my notation. A signal may have more 
than one home, but only if all its homes are in the same nest. <*KVL-2> 
Given a port, the function PORT-SIGNAL should give its signal. 

To make up for the absence of homeless signals, many actions manipulate 
signal descriptions, lambda-expressions from signals to truth values. For 
example, the formula 

{CONVERT (device) (signal description! |signal relation|] 
means "device converts any signal appearing on its INPORT which satisfies the 
description into an OUTPORT signal which bears the relation to the input 
signal." An example of the use of this predicate appears in Chapter I. 
Another is. 
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[DESIGN (X (X) 

(CONVERT ?X 
(X (SI) 

(FORALL (F) 

(IMPLIES (/> ?F MHz) 

(- ((FOURIER-TRNSFRtl (TFUN ?SD) ?F) 

0))) ) 

(A (SI S2) 
(FORALL (F) 

(AND (IMPLIES (/< ?F 180kHz) 

(- ((FOURIER-TRNSFRM (TFUN ?S2)) 
?F) 
8)1 
(IMPLIES (/> ?F 108kHz) 

(- ((FOURIER-TRNSFRM (TFUN ?S2) ) 
?F) 

((FOURIER-TRNSFRM (TFUN ?SD) 
?F))))) )))] 

This formula illustrates the use of the Fourier transform of a signal. 

The DESI+ZORCH system actually lacks any deep mathematical understanding 
of transforms. Instead, it summarizes the frequency-domain behavior of a 
signal with a frequency picture of its time function. A frequency-picture is 
a tuple of "frequency features." A feature is specified as (FF |freq| 
|landmark|]. <*FF-FREQ, FF-LANOMARK> A landmark may have a shape, height, and 
width, written FL -SHAPE, FL -HEIGHT, or FL-WOTH. In general any particular 
characteristic is optional, but the assumption is that a feature has non-zero 
size. These are similar to the human conventions for such descriptions. 

Signal characteristics can have these values: 

SHAPE — may be SPIKE, HUMP 

WIDTH — a HUMP may be SHARP or FUZZY 

HEIGHT — a number 

The notation [SERIES |freq| |delta freq| |shape| |fun|] defines an 

infinite frequency picture consisting of a row of features of the given shape, 

at interval of delta freq, starting at the given frequency. The height of the 

nth landmark in the row is given by fun. This function must be decreasing (as 

it will be in all physical applications). 
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(Th'19 nay of reasoning about the frequency domain is in many ways closer 
than straight Fourier transforms to the way humans think about it, and reveals 
more about the signals. This is a good illustration of the point that using a 
logical notation does not commit you to a "mathematical" treatment of a 
domain. ) 

For example, a square uave of frequency f offset by half its amplitude A 

has frequency picture picture 

[<(FF 0Hz LANDMARKS) 
!#(SERIES |f| (* 2 |f|) 

SPIKE (A (N) (* M| (// 4 (* ?N PI))) ))>) 

where 

[FL-SHAPE LANDMARK079 SPIKE) 
and [-/> ' (FF -HEIGHT LANDMARKS) (// \A\ 2)1. 

The usual graphical notation for the Fourier transform of an offset square 

uave is, of course. 



Frequency 



f 



2f 



3f 



4f 



5f 



6f 



7f 



Figure IV. 5 Fourier Transform of an Offset Square Wave 
Time-domain signal attributes are also known to the system. A function 
may be periodic with a certain period, expressed as [PERIODIC |tfun| 
|period|l. If so, lONE-PERIOO |tfun|) is a function which is zero everywhere 
except from -T/2 to T/2, where [(ONE-PERIOD |tfun|) ?T) - [|tfun| ?T) . (T is 
the period of the function.) Others are (following (A. Brown, 1975)) the DC 
offset of the signal; amplitude, the height of a periodic signal; phase with 
respect to another signal; etc. 
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A large set of formulas is concerned with computing the frequency picture 
of periodic signal descriptions expressed in time-domain terms. <*PERI0DIC- 
FREQ-PIC> 

Besides these intrinsic descriptions, there are "extrinsic" signal 
properties like "carrier," or "modulation," or "distortion." These concepts 
would be necessary for a system that designed or redesigned radios, which are 
a level above that which I have focused on. (This is the chief difference in 
emphasis between Brown's approach to signal description and mine.) It appears 
to me that it would be easy and instructive to add this knowledge to DESI, but 
that it would be a slight detour. 

Of course, the descriptions of signals are of interest only so far as they 
support comparison. Ue are interested in designing circuits which convert 
from one kind of signal to another; given two pictures, a good description of 
the transformation from one to the other will help us to retrieve useful 
plans. This will be described below, in Sect. IV. B. 

IV. A. 3 Multiple Models of Linear Systems 

A great advantage of a linear domain such as elementary electrical 
engineering is that it may be profitably attacked by linear, time-independent 
methods in many cases. In addition, the fact that analysis is of a closed 
network makes a forward-deduction scheme practical. (Cf. (Nevins, 1974c, and 
Sussman and Stall man, 1975).) 

The folowing types of quantities are to be dealt with by an electronics 
analyzer (see Sect. IV. C): 

physical quantities like voltages and currents 

component control quantities like resistances and capacitances 
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The kind9 of questions to be answered are: 

Uhat is the the value of 9ome physical quantity in a given circuit? 
Uhat are the values of derived control quantities like the Thevenin 
resistance or gain of a circuit? 

Often these questions are with respect to a circuit of interest as given, 
but ju9t as of ten expl ici t or implicit reference is made to a derived model of 
a circuit. For example. 

The DC gain of a circuit is the gain of the DC model of that circuit 

The Thevenin resistance of a circuit i9 the resistance of the circuit when 
it is disconnected from its environment and its independent sources are set to 
zero. 

The impedance of a circuit is its (complex) resistance in its "sinusoidal 
steady state" model. 

etc. 

These models are generated by the use of FRAME, N, and T formulas (see 

Sect. II.B.2) in the data base. Many of these appear in the schemata for 

various devices, but the FRAME axioms occur separately. Together they define 

the models as follows: 

(1) ((DC)] The DC model of a circuit i9 the same circuit with all frequency- 
dependent features nulled in a device-dependent way. Thu9 we have <*FRAME-DC> 
plus formulas I ike 

[IMPLIES (IS CAPACITOR ?X) 

(AND (N (DC) '(IS CAPACITOR ?X)) 
(T (DC) (IS OPEN ?X)))1 

(cf. <*CAP-PKT>) for frequency-dependent components like capacitors. The (DC) 
of an already-DC model is itself, because these components can be nulled only 
once. <*DC-IDEM> Thu9 (see Chapter II), we have 

[N (DC) ' (T ?R (FRAME (DC) <(HERE)>))] 
IT (DC) (-/> '(DC) (HERE))) 



(2) [(INC)l The incremental model of a circuit. <*REF-INC, FRAME-INC, INC- 
IDEM> 
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(3) [SSS |s|] The sinusoidal-steady-state model for complex frequency 3. 
<*REF-SSS, SSS-IDEM, FRAME-SSS> (In this model, all linear devices act like 
resistors uith complex resistances or impedances.) 

(4) [ISOLATE |trmin 1| |trmin 2|J The model obtained by disconnecting the 
given terminals from whatever nodes they appear in. <*IS0LATE-DEFN-1, 2, and 
3> (These terminals are usually nodes in a composite device.) It is used for 
calculating Thevenin resistances. <*REF-IS0, FRAME-ISO, IS0-lDEM> 

(5) [PASSIVE] The network with all active sources $et to zero. Also used for 
calculating equivalents. <*REF -PASSIVE, FRAME-PASSIVE, PASSIVE-IDEM> 



IV. B Electronic Design Knowledge 

The knowledge in ZORCH is meant to mesh with the knowledge in DESI so as 
to bring about useful behavior. Generally DESI provides the plan framework 
and some quite general heuristics, while the solid stuff is in ZORCH. This is 
true of knowledge about design actions. 

I V.B.I Rephrasing Electronic Design Problems 

Uhen it comes to rephrasing design, DESI does little more than provide the 
concept of "d-shard" and the policy that every shard in the initial explosion 
must lead to something useful. (Chapter HI) Most of the knowledge is in 
ZORCH. Here are defined the interesting control quantities of this domain: 
voltage gain <*V-GAIN-SHARD>, and input and output impedance <*INPUT-Z-SHARD, 
OUTPUT-Z-SHARD>. These lead to side-tasks which constrain control quantities 
ivla <*CQ-SHARD> in DESI), but they also lead to domain-dependent "d-features" 
regarding the ranges of these quantities. These all end up affecting the way 
in which device schemata are selected. 

Besides this sort of control-value redescr iption, more devious things can 
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happen. If a d-shard of the form [(X (|i/|) (CONVERT ...)]] appears in the 
middle of the explosion, it causes an inferential subtask to appear. <*CVT- 
EXPLOOE> This subtask mimics the super task for exploding design properties, in 
that it manipulates formulas describing signals, breaking them into "signal 
shards." These signal shards are then parsed into d-shards and ultimately 
into d-features, side- tasks, and core device types. 

There are two complementary paths this deduction can take. One <*FREQ- 
DOM-REPHRASE> tries to compute the frequency pictures of the input and output, 
then find a transformation ("FREQ-PIC-TRANS") between them. The output of 
this deduction is an object of the form (LOU-PASS |cutoff|], [HIGH-PASS 
|cutoff|], [MODULATE |freq|], etc. This transformation becomes a signal 
shard. This language for describing frequency transformations is not as 
general as it could be. On the other hand, it is quite extensible, and 
reflects everything I know about the subject. 

The other rephrasing method <*TIME-DOMAIN-REPHRASE> merely searches for 
certain simple functional relationships between the time values of the input 
and output. (This has not been implemented yet.) 

The system tries to choose <*CVT-CHOICE> between these two ways of 
rephrasing on the basis of simple criteria. For example, if the input 
predicate to CONVERT doesn't mention the input at all, the transformation is 
more likely to be a function of signal values, so the time-domain is ruled in. 

IV.B.2 Reconciling Partial Solutions 

Thi3 kind of information arises in two places: generating and choosing 
core device-types, and choosing ways of making devices. (As in Sect. Ill .0. I 
am not including information about patching failing constraints.) 
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It Is important to note that computation regarding a circuit is to be 
postponed whenever possible until after the design rephrasing plan. This is 
because (a) the ideological intent is for this phase to be concerned with 
problem, not solution, manipulations and (b) the pieces of problem are lying 
around in the wrong form to be noticed during deductions. 

So, during the d-explosion and subsequent re-parsing, OESI is more 
interested in seeing the pieces than putting them together. This orientation 
means that ordinarily the generation of tuo core device-types is an error; the 
error will be revealed by the choice protocol for the CORE-FINDER step of Fig. 
III. 7. 

ZORCH makes up for this by allowing the design rephraser to pass the buck 
under certain circumstances. <*L I NEAR-GROUP I NG> If one of the competing core 
device types is linear, ZORCH rules them together into the artificial device- 
type [GROUP < -device types- >] . GROUPing means CASCADing in some as yet 
undetermined order. <*MAKE-GR0UP-1 . MAKE -GROUP -2, ttAKE-GR0UP-3> The idea is 
to postpone deciding among them or composing them until the constraints and 
features have been sorted out. After all, you can be pretty sure a linear 
device will not interfere too badly uith what it is connected to. 
("Cascading" two device-types means making one of each and coupling them. See 
below. ) 

This is the somewhat bedraggled method by which core-device-type choice 
can give rise to cascades. This should be a rare event. Normally, the device 
classes introduced do their job harmoniously enough so that one superordinate 
or basic category is natural for describing a desired circuit. In that case, 
the category will wind up as part of the central MAKE task of a design 
network. (See Fig. 1 1 1. 8.) Here cascading will reappear in a much more 
disciplined way as the choice of which subordinate or specialized device type 
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to use. 

In choosing a way to MAKE a known circuit type such as an amplifier, often 
more than one suggested subtype comes to mind. This will be because various 
subtypes are indexed by associated D-NOTES. <*M0D-V-GAIN, HIGH-V-GAIN, etc> 
If more than one device is triggered by a constellation of D-NOTES, it may be 
for two standard reasons. First, a control quantity like gain may fall into 
two ranges. (<*V-GAIN-SHARD> and its ilk specify overlapping ranges, for 
example.) If so, a value falling in the ambiguous region may necessitate 
differential diagnosis in the subsequent choice situation. One might have to 
decide between an op-amp or common-emitter amplifier on the basis of cost, 
convenience, etc. 

Second, the two suggestions may answer to different subrequirements, in 
which case they must be combined in some way (or one subrequirement must be 
foregone) . 

Rules for performing these functions for the device type AMPLIFIER are 
given in the packets defined by <*CH00SE-AMP>. This contains principles like, 
"If high bandwidth is required, prefer a multi-stage amplifier to a single 
high-gain stage"; and, "If one option (e.g., a common-collector) has been 
proposed because of its input impedance, and another for some other reason, 
cascade them in that order." 

The fact that in using the rules of <*CH00SE-AMP> the system is restricted 
to a well-defined situation helps to make those rules concise and to the 
point. This attests to the organizing power of the concept of "superordinate 
device type." It is difficult to think of a natural choice situation in which 
the statement of the problem does not bring to mind a set of rules organized 
around some such type. It appears that a large part of the training of 
technicians and engineers is the accumulation of these sets. 
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Cascading two device types is MAKE-ing an object of the abstract type 
[CASCADE |type 1| | type 2|J. <*f1AKE-CASCADE> This consists of a 
straightforward plan to MAKE a device of each type and COUPLE them. The 
components of the result are the tuo devices. In cascading two device types, 
it is wise <*C0UPLE-GENERAL-1, C0UPLE-GENERAL-2> to use the most general 
specializations of the device types involved. These are defined by the 
predicate MOST-GENERAL-SPEC (defined in Appendix 2). An example is the device 
type GENERAL -CE, which is the most general common-emitter circuit. 

Coupling comes under the heading of a circuit-change operation. (Cf. 
Sect. III.B.4) 

IV. B. 3 Changing Circuits 

Except in the dullest circumstances, a circuit schema cannot be 
instantiated merely by binding a few variables. After it has been plugged in, 
its "expansion obligations" become active. (In the case of a productive 
"device type" like (CASCADE ...], these obligations are part of the plan that 
makes a device of that type.) These expansion obligations are the normal 
place in which circuit-changing tasks arise. (If failure-correction were 
implemented, this uould also be a common source of circuit changes, of 
course.) 

The circuit-changing actions defined so far include biasing, coupling, and 
fixing voltages. These actions come in specialization hierarchies, and they 
interact in interesting ways. 

Biasing bipolar junction transistors (BJTs) is defined by <*BJT-BIAS-NET> 
as three important tasks: fixing the collector current (Iq), reverse-biasing 
the col lector -base junction, and fixing the base-emitter voltage (Vg E ). For a 
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typical one-stage transistor amplifier, these tasks are subsumed by the 
specific suggestions in <*TYPICAL-BJT-ONE-STAGE-BIAS-PLAN>. 





Reverse 
-Bias 
CB 





a 



Getv d 



-►o o — ►o o — jrO 

Connect Get Connect Get Connect 

to base Voltage to Resistor to 

Source Collector Emitter 



BJT-BIAS-NET 



SPEC 

-SCHEMA 



TYPICAL - 
BJT-ONE- 
STAGE- 
BIAS 



Figure IV. 6 Bias Plans 
This plan defines the bias networks of Fig. 1.2. 

The biasing plan interacts with the coupling plan for BJTs <*COUPLE-NET>, 
which itself has several SPEC-SCHEMAs. The general plan is shown in Fig. 
IV. 7. 
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Figure IV. 7 General BJT Coupling Plan 
The interaction start9 with the rule that coupling is considered before 
biasing. <*COUPLE -BEFORE -B I AS> (Cf. Fig. 1 1.5.) The reasons for this rule 
are that decisions made during coupling often influence the way in which, 
biasing is done; and that coupling components perform many biasing functions. 
These interactions depend upon the particular coupling network chosen. The 
rule packets <*COUPLE-CE-X-HINTS, COUPLE -CC-X-H I NTS> suggest particular 
subnets to be used. One of these <*CE-0IR-V0L-C0UPLE-PLAN> is shown in Fig. 
IV. 8. (The others are as yet unwritten.) 
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Figure IV. 8 Common-Emitter Direct Voltage Coupling 
Choosing this plan amounts to settling on direct coupling with voltage as the 
medium. Picking it reduces tasks from the bias network and main coupling plan 
without further examination. 

Two plans for fixing voltages is shown in Appendix 3. <*VS-FIX-V, VD-FIX- 
V> The first is used to set voltages absolutely. The second is used for 
setting voltages, such as the base voltage of an transistor, which are to be 
allowed to change incrementally. 
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IV. B. 4 Electronics Analysis Knowledge 

In the usual case, there i9 no special electronics analysis knowledge. 
Device properties are expressed by numerical constraints (Chapter III), which 
interact with each other and SELECT-VALUE tasks to produce results. In the 
ideal case, the deductions involved are always "one-step deductions" (Stallman 
and Sussman, 197G) of the value of one variable at a time. (I have taken much 
of the analysis knowledge practically verbatim from Stallman and Sussman' s 
data base.) 

Besides calculations of physical quantities and component values, there is 
also the problem of computing values of "generic control quantities" (Sect. 
II I.A.I). These are quantities like "voltage gain," which 19 defined 
genericalty as, "The value of the voltage on the outport over the value on the 
inport," but whose symbolic and numerical values depend o.n the circuit 
involved. Uhen a generic attribute value is constrained, a task will be 
created to calculate it. <*GENERIC-CAS-DO in Appendix 2> 

How this is done depends on the quantity to be calculated. For example, 
to calculate the Thevenin impedance of a circuit from two terminals, you must 
enter the reference point (ISOLATE |trmin 1| |trmin 2|], fix the voltage at 
the two terminals, and calculate the current. (Th)9 technique i9 probably 
beyond the current competence of NASL. For a precise account of how to do it, 
see Doyle, 1977.) 

Very little electronics analysis knowledge has been implemented. (See 
Sect. IV.D. below.) fly implementation has focussed on qualitative reasoning 
about design; it complements the work of Stallman and Sussman (1976) on 
quantitative analysis. 



IV Electronics 146 



IV.C Device Schemata 

The last part of Appendix 3 is a bag of device schemata. These include 
primitive components and a few composite devices. Host of the primitive 
components are defined entirely by one or tMO constraints and some T and N 
formulas describing their behavior from various derived models. The 
transistor schema <*BJT-DEFN>, as you might expect, has a more complicated 
structure. Besides the physical constraints on its terminal voltages and 
currents, every transistor must be biased into its desired region. Thus, a 
composite device schema that specifies that its transistor is active will 
automatically acquire an expansion obligation to bias the transistor. 

There are several device schemata for composite devices defined at the end 

of Appendix 3: 

GENERAL-CE — The most abstract common-emitter circuit 

TYPICAL -CE -- The circuit shown most often in textbooks, which is derived 
from the more abstract one 

GENERAL -ECP — The most abstract emitter-coupled pair 

ECP-OC-ANP -- One of many circuits that can be derived from the ECP 

VD — The humble voltage divider 

RC — The filter, not the cola. 

The relation between the ECP-DC-AriP and its "soul," the GENERAL -ECP, is 

shown in Fig. IV. 9 
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Figure IV. 9 General and Specialized Emitter-Coupled Pairs 
A similar relation exists between GENERAL-CE and TYPICAL-CE. In defining 
these relations, extensive use is made of the predicates REDUCE and FUNCTION, 
defined in Appendix 2. REDUCE declares that some set of tasks is a complete 
subnetwork of the reduced task. [FUNCTION |dev| |reduced taskj] is a special 
case, used in device schemata, which declares the existence of an abstract 
task for acquiring the device dev, and specifies that this task is sufficient 
to accomplish the task to be reduced. 

The function tOBL |dev| |action|] denotes an expansion task created by the 
use of rule <*EXPANSION-OBLS-DO>, defined in Appendix 2. 



IV Electronics 148 



1V.D Programmer' 9 Guide 

A3 I have pointed out in several places, the information in ZORCH is 
sketchy. I hope this hasn't harmed the clarity of my presentations I have 
provided an example of every kind of construct I discussed. The knowledge 
shown is still in the process of being debugged and assimilated into DESI: 
there has not been time to be complete. As it is, implementation and 
debugging cannot keep up with generation of new formulas. (See Chapter V.) 

This section is included as a guide to anyone uho wishes to add 
information to the DESI system (or its successor). It consists of a list of 
all the kinds of information that are missing. (Filling in these holes should 
be a matter of follouing the principles of Sect. III.E and imitating the 
formulas that already exist.) 

> Rephrasing can be extended. More principles are needed for comparing 
frequency pictures; some knowledge of Fourier transforms (as opposed to 
frequency pictures) is necessary in order to generate precise side tasks. 

> The time-domain information is non-existent in Appendix 3. The time- 
domain rephrasing problem comes down to trying to find a functional 
relationship between two axiomat ical ly described objects. This is not easy. 

> Many more circuits are needed. Most of the amplifier types mentioned in 
<*CHOOSE-AMP> and its satellites are undefined; power amplifiers are a glaring 
omission. The superordinate category of "filter" is entirely absent. There 
9hould be a theory of LC filters and when to use one of them. This should 
work with a theory of matching impedances during coupling of power stages. 
Time-domain rephrasing will be useless unless it is used to index clippers, 
rectifiers, and other "operational" circuits. 

> Coupling circuits are many and varied. Only one specialized circuit is 
shown in Appendix 3. (See Fig. IV. 8.) One difficulty I didn't mention in 
discussing coupling is choosing polarities of bipolar transistors. These are 
normally NPN, but coupling them directly often constrains them to be of 
opposite polarities. 

> Some of the information shown hanging off circuit diagrams in Chapter I, 
especially interface constraints, has not been represented in the circuit 
schemata of Appendix 3. For example, the system function of the RC filter 
will not be what it claims to be if something is connected to it. 
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V Results 

The major result of this research to date is the existence of NASL, DESI. 
and ZORCH. The experience I have had in defining the NASL notation and 
applying it to electronic circuit design is enough by itself to suggest 
certain conclusions. These are the substance of Chapter VI. 

Of course, the claims I make there will be not be decisively proven until 
the program has been debugged and the ZORCH knowledge base has been completed. 
These activities are proceeding, and preliminary results are reported in Sect. 
V.B below. 

Since DESI is intended to be a working system, and since people may wish 
to experiment with it or with the NASL interpreter, these are described from a 
practical point of view in Sect. V.A. I would appreciate comments from those 
who try it out. 



V.A Using DESI 

V.A.I Loading and Running the Program 



To run my programs on the MIT AI Lab time-sharing system, type 
: I dvm; 
at DDT, then 

(load nasi) 
at LISP. This will load the interpreter and leave you in the LISP read-eval- 
print loop. (The reader and printer are not the standard LISP mechanisms, but 
that shouldn't matter.) Now you can load NASL assertions from any file you 
choose (using DEFhLA; see Appendices 2 and 3). To load the designer in, type 
(load desi) instead of or in addition to the above; to load the electronics 
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knowledge, type (load zorch) . (Or load the binary file TS DESI, to save a lot 
of time.) 

To run NASL, type 

(9tart |action|) 
at LISP, where action is a formula or list structure of the form [/:TASK ...] 
or t|action funct ion| . . .] . (In the latter case, if the action has outputs, 
type (start |action| |outputs|).) NASL will begin execution, adding the new 
action to i ts task network. When the network is empty, it will return the 
output variables of action if any. It mil also remain in the data pool of 
the action performed, typically a DESIGN, so that you can run new tasks in the 
same environment. 4 

V.A.2 DESI Talks to You 

Uhen NASL runs into trouble, or needs the ansMer to a symbol -mani pu I at ion 
problem, it stops and asks' you questions to try to help itself out. "Trouble" 
is defined as the failure of the choice or rephrasing protocol to achieve its 
aims. In either case, the system stops and tells you its trouble, then asks 
various questions. For example, if it cannot make up its mind after applying 
all the known choice rules, it will ask i f it should choose at random. Yes/no 
questions are answered by typing •'yes," "y," "no," or "n." Other questions 
will be requests for formulas. (If you type an S-expression where a formula 
is wanted, NASL will convert it.) 

Three standard questions and the reactions to their answers are: 

> "Do you want to see the reasoning involved?" Answering affirmatively 
causes NASL to re-run the most recent relevant deduction, with the switches 
STP-TRACE-DEPTH* and RECORD-SEE-DEPTH* set to values that let you see the 
steps. (See below.) 



V Results 152 



> "Break?" If you ansuer "yes," the system wi 1 1 give you a LISP break 
loop. This is usually used for adding new information to the system uith 
further DEFMLAs. (DEFMLA may be used to redefine old formulas, too.) Uhen 
you return from the break, the next question in NASL's list will be asked. 

> "Try again?" Don't say "yes" unless you've taken advantage of the break 
loop and added a neM choice principle, a missing axiom that was needed by the 
Ia9t deduction, or 9ome other rule. 



V.A.3 You Talk to DESI 

There are several useful programs for getting debugging information or 

explanations of behavior from DESI. 

(TASK-NET-DUrtP) causes the entire active or pending task network under 
your original request to be printed Out in a somewhat readable fashion, with 
indentation, successor pointers, etc. (This function takes an optional task- 
name argument; if it is omitted, your original request is used as a default.) 

(UHY | task | ) causes the task network above the named task to be dumped. 
Notice that asking this question about a frozen task will show you part of the 

te I eo logical structure of the device it appears in. 

(SUPPORT I fact I ) prints the supporters of the fact. 

A^nllI ( Dc RP0SE ^ 1 ! devi " |, Points out the supertasks associated with MAKE-ing or 
HLUUiMh-mg the device (depending on what kind of records of the historu of 
the device have been kept). 

I am being a little vague about the precise formats of these functions, 
both because the system encourages you to be vague (it will try to figure out 
whether you are referring to formulas by name or pattern): and because the 
features these functions support are changing rapidly. 

Some useful statistics-gathering functions are defined in the file SNAP. 
The statistics gathered include running times overall, time spent doing 
matching and indexing (important low-level functions of a rule-based system), 
and success of the indexer in keeping garbage from reaching the matcher. 
Typing "(SNAP)" at LISP causes these statistics to be printed out. "(SNAP 
RESET)" resets them; this must be done once to turn them on. (Collecting 
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these statistics slows things down somewhat.) 

There are several switches whose settings affect the verbiage produced by 
the NASL system. These switches are printed by the function SHOU-SUI TCHES, 
defined in SNAP. The switch NASL-TRACE-DETAIL*. an integer from to about 5. 
defines how much the interpreter will tell you about its every move. The 
switch STP-TRACE-DEPTH* controls printing of major sub-goal information by 
STP; if zero, nothing is printed. Similarly, RECORD-SEE -DEPTH* controls 
printing of data-base alterations. Both of these switches are normally zero; 
the system sometimes turns them on to display inferences or model effects. 
(As in Sect. V.B, below.) 

V.B Experimental Results 

The DESI system is still being debugged. Consequently, it has never 
designed a circuit all the way through. It has done simple choice analysis. 
trivial equation solution, and" some rephrasing of simple conjunctive design 
problems. 

Most of the time, the system runs well. Forward deduction and task 
reduction occur in a reasonable amount of time; watching the trace on the 
screen is a pleasant experience. The NASL language is easy to program in; it 
encourages an incremental style of programming in which partial plans 
interact. If an unforeseen interaction occurs, the presence of all task 
information in the data base usually makes the trouble easy to find; fixing it 
is usually a matter of adding a new rule. When it isn't, the problem usually 
turns out to be a syntactic error in a rule; I strongly recommend to future 
designers of predicate-calculus systems with large rule bases that they 
include checks of syntax (such as proper number and type of arguments to 
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predicates) at the time a rule is read. In such a system, a wrong rule is 
often overlooked entirely. 

Calls to the theorem prover tend to 9 low things down. This not because of 
any combinatorial explosion, but probably because of the theorem prover' s 
carefulness in checking subsumption and other special cases which are normally 
irrelevant. The theorem prover is probably too complex for its own good; the 
next such program I write will be much more like Conniver. (McDermott and 
Sussman, 1973) 

Furthermore, the evaluation mechanism (Appendix 4), which i9 normally 
quite efficient, wastes much time in other circumstances. The evaluator is 
called whenever the right-hand side of an implication is detached during 
deduction. It tries to apply reduction rules to every new subexpression of 
the detached formula. This isn't nearly as expensive as it sounds, because 
one quick index call is enough to check the (very common) case where there are 
no applicable rules. Unfortunately, in detaching the right-hand 9ide of a 
large implication I i ke <*+DESI -2> in Appendix 2, there is an embarassing 
pause.. I am putting up with this for the time being, but it is clear that 
this is a job for some further pragmatic-predicate mechanism. 

A9 it stands, the system with ZORCH loaded occupies a huge amount of core. 
As incomplete as it is, it takes up about 220K of 36-bit word storage. About 
58K of this is the LISP system and my low-level utilities, and 130K is list 
space, 70X (about 90K) of which '19 occupied. Of this, about 30K consists of 
circuit diagrams for the five device types defined in ZORCH! I am sure this 
can be brought down by judicious rearrangement of consequent vs. antecedent 
deduction; the problem appears to be overenthusiast ic forward reasoning while 
setting up device schemata. However, a lot of storage is required to set up 
and index packets, whether they are used later or not. To duck this probelm, 
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in the sample runs given below, large conjunctions of the form t/:PKT ...] 
were actually implemented as ordinary formulas like [AND ...]. In the long 
run, we are going to have to confront the question of organizing secondary 
storage for use by AI programs. 

There are three experimental results to demonstrate. First (Sect. V.B.I), 
I present DESI's attempt to design a simple amplifier. Then I show its 
pitiful approach to the filter-design problem I described in Chapter I. In 
both these cases, the program crashed due to bugs before going as far as it 
is, in theory, capable. Finally, in Sect. V.B.3* I discuss some research with 
Jon Doyle into the relation between NASL and NOAH. (Sacerdoti, 1975) 

V.B.I A Simple Amplifier 

Here is a sample output from a run of DESI on the first problem in Chapter 

I, with NASL-TRACE-DETAIL* set to 3. fly comments start with ";". The output 

has been edited to reJieve the' tedium. The dots "..." indicate omissions. In 

this and the next section, apparently random "!'s" in the output are caused by 

garbage collection, one exclamation point per collection. Long strings of 

these marks are indicative of long pauses between outputs. 

j The system was started with by typing 
{ (start * [design ...] ' [<' (winner)>l : 

(CREATING TASK 

[:TASK (*DES*) <> (LAMBDA NIL 

(DESIGN (LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
(- (V-GAIN ?X) 5) 
(- (INPUT-Z ?X) 30008))))) 
<' (UINNER)>)) 
(ENABLED U*DES*)]) 
(EXECUTING U*DES*)] ...) 
(TASK [(*DES*)) BEING REDUCED) 
(TASK I(*DES*)] TO BE REPHRASED) 
(CREATING TASK [:TASK (REPHRASER (*DES*)) 
<> 
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(LAMBDA NIL 

(: REPHRASE (*DES*) tOESIGN (LAMBDA (X) 

(AND ...))] 
<' (WINNER) >)) 

(ENABLED (REPHRASER (*DES*)1) 
(EXECUTING ! (REPHRASER (*DES*)] 

t: REPHRASE (*DES*) (DESIGN (LAMBDA (X) 

(AND (OEV-TYPE ?X AMPLIFIER) 
(- (V-GAIN ...) S) 
(- (INPUT-Z ...) 30909)))] 
<MUINNER)>] 
[<>] ) 
(TASK [REPHRASER (*DES*H BEING REDUCED) 
(TASK (REPHRASER (*DES*)] REDUCED TO 
[ : DO-SUBNET (DES I -REPHRASE-PLAN 

[(LAMBDA (X) (AND ...))J (*OES*) <MUINNER)>) 
<>]) 

<>]) 
;Here are the tasks from the DESIGN rephrase plan <*+DESI-2> 
(CREATING TASK hTASK (EXPLODER PLAN0380) 
<> 
(LAMBDA NIL 

(D-EXPLODE [(LAMBDA (X) 

(AND ...))))) 
<>]) 
(CREATING TASK (:TASK (ACCOUNT-FOR-ALL PLAN0388) 
<> 
(LAMBDA NIL 

(ACCOUNT-FOR-ALL -SHARDS [(LAMBDA (X) 

(AND ...))))) 
<>)) 
(CREATING TASK [:TASK (CORE -FINDER PLAN0389) 
<> 
(LAMBDA NIL 

(:FINO (LAMBDA (+OT) 

(CORE-DEV-TYPE I...J ?+OT)))) 
<' (CORE-DT PLAN#380) >] ) ! 
(CREATING TASK (:TASK (MAIN-TASK- I NFERER PLAN0389) 
<' (CORE-DT PLAN#380)> 
(LAMBDA (+DT) 

(: INFER '(AND (STASK (MAKER ...) (*DES*) 
<> 
(LAMBDA NIL 

...) 
<...>) 
(:MAIN (MAKER ...) (*DES*) ) ) 
< (CORE -FINDER PLAN#388)>)) 
<>]) 
(CREATING TASK (:TASK (SIDE-TASKS-FINDER PLAN#389) 
<> 
(LAMBDA NIL 
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(: INFER MFORALL (+ST) (-> G (SIDE-TASK ...) 

(EXISTS ...))) 

(CREATING TASK (:TASK (FEATURES -FINDER PLAN0388) 
<> 
(LAMBDA NIL 

(: INFER MFORALL (+FT) (-> G (D-FEATURE ...) 

(EXISTS ...))) 
<>)) 

(CREATING TASK I: TASK (GATHERER PLAN//388) 
<> 
(LAMBDA NIL 

(: INFER MrREOUCED (*OES*) ) 
< (CORE-FINDER PLAN#388) 
(SIDE-TASKS-FINDER PLAN0388) 
(FEATURES-FINDER PLAN#388)>)) 
<>]) ! 
(BLOCKED fMAIN-TASK-INFERER PLAN#380]) 
(BLOCKED (CORE-FINDER PLAN#380] ) 
(ENABLED [ACCOUNT-FOR-ALL PLAN0388] I 
(BLOCKED (EXPLODER PLAN#388J ) 
(BLOCKEO [GATHERER PLAN//3881 ) 
(BLOCKED [FEATURES-FINDER PLAN0388] ) 
(BLOCKED [SIDE-TASKS-FINDER PLAN#388] ) 

I The only task which is enabled is the policy-setup for shard 
5 account ing — 

(EXECUTING [ACCOUNT-FOR-ALL PLAN0388J 

[ACCOUNT-FOR-ALL -SHARDS [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 

(- (V-GAIN ...) 5) 

. .. , (- (INPUT-Z ...) 38888)))]] 

l<>] ) ! 

(TASK [ACCOUNT-FOR-ALL PLAN0388] 

BEING REOUCEO) 
(TASK [ACCOUNT-FOR-ALL PLAN0388] 

REDUCED TO [:PRIM *SETUP] ) 

;But the first real task is the exploder 

(ENABLED (EXPLODER PLAN#380] ) 

(EXECUTING [EXPLODER PLAN0388] ' 

[D-EXPLODE [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 

(= (V-GAIN ...) S) 

(= (INPUT-Z ...) 38888)))]] 
[<>] ) 

(TASK [EXPLODER PLAN#388] BEING REDUCED) 

(TASK [EXPLODER PLAN#388) REDUCED TO 

[tINFER * (D-SHARD ((LAMBDA (X) (AND ...))] 
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[(LAMBDA (X). (AND ...))]) 

;The system prints out a lengthy list of deductions from this inferred 
j "d-shard": 

(INFERENCES MADE BY (EXPLODER PLAN#380] 

--) 
(RECOROING [D-SHARD [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
(- (V-GAIN ...) 5) 
U (INPUT-Z ...) 38880)))] 
[(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
(= (V-GAIN ...') 5) 
(- (INPUT-Z ...) 38888)))]) 
8) 

;It turns the elements of the conjunction into shards 
(RECORDING [:GEN (NOT (ELT ?+C A 4 <IDEV-TYPE ?X AMPLIFIER] 

[- (V-GAIN ...) 51 
[- (INPUT-Z ...) 388881 >)) 
(D-SHARD [(LAMBDA (X) 

(AND (DEV-TYPE ... AMPLIFIER) 
(- ... 5) 
(- ... 38088)))) 
[(LAMBDA (X) _?+C*4)])) 
8) ! 

;The first of three major shards: 

(RECORDING [D-SHARD [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
(« (V-GAIN ...) 5) 
i- (INPUT-Z ...) 38888)))] 
[(LAMBDA (X) (- (INPUT-Z ?X) 38880))]] 
0) 

• • • 

;The "«" tells DESI one side might be a control quantity: 

(RECOROING [POS-CQ-SHARD [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
U (V-GAIN ...) 5) 
(- (INPUT-Z ...) 30800)))] 
[X] [INPUT-Z ?X1 [30000]] 
0) 
(RECORDING t:GEN (NOT (AND (NOT (CONTAINS [30000] [?? X])) 

(=> ' (DEN ...) ?F~9) 
(CONTROL-ATTRIBUTE ?F A 9) 
(»> '(DEN ?+F A 9) ?F A 9))) 
(SIDE-TASK [(LAMBDA (X) 

(AND (DEV-TYPE ... AMPLIFIER) 
(- ... 5) 



V Results 159 



(- ... 30009)))] 
[(LAMBDA (X) (CONSTRAIN <...> (LAMBDA ...)))])] 
0) 

(RECORDING (POS-CQ-SHARO [(LAMBDA (X) 

(AND (OEV-TYPE ?X AMPLIFIER) 
(- (V-GAIN ...) 5) 
(- (INPUT-Z ...) 30000)))) 
[X] [30800] [INPUT-Z ?XJ] 
0) 
(RECORDING [:GEN (NOT (AND (NOT (CONTAINS [INPUT-Z ...J 

[?? X])) 
(-> ' (DEN . . . ) ?F A 9) 
(CONTROL-ATTRIBUTE ?F*9) 
U> ' (DEN ?+F A 9) ?F A 9) ) ) 
(SIDE-TASK [(LAMBDA (X) 

(AND (DEV-TYPE ... AMPLIFIER) 
(- ... S) 
(- ... 30900)))] 
[(LAMBDA (X) (CONSTRAIN <...> (LAMBDA ...)))])] 
0) ! 

;Having noticed that INPUT-Z is a control attribute, it uses the rule 
; INPUT-Z-SHARD to classify the desired impedances 

(RECORDING [:GEN (NOT (- 30000 ?Z*7)) 

(AND (sGEN (NOT (> ?Z A 7 300000.0)) 

(O-FEATURE [(LAMBDA ...)] 

[RANGER INPUT-Z VERY-HIGH])) 
(:GEN (NOT (AND (> ?Z A 7 1500.0) 

(< ?Z"7 500000.0))) 
(D-FEATURE [(LAMBDA ...)] 

[RANGER INPUT-Z HIGH])) 
(:GEN (NOT (AND (> ?Z A 7 500) 

(< ?Z A 7 2009.0))) 
(D-FEATURE [(LAMBDA ...)] 

[RANGER INPUT-Z MODERATE] ) ) 
(:GEN (NOT (< ?Z A 7 1000)) 

(O-FEATURE [(LAMBDA ...)) 

[RANGER INPUT-Z LOU])))) 
0) 

(RECORDING [AND (sGEN (NOT (> 30000 300000.0)) 

(O-FEATURE [(LAMBDA (X) (AND ...))] 
[RANGER INPUT-Z VERY-HIGH])) 
(:GEN (NOT (AND (> 30000 1500.0) (< 30000 500000.0))) 
(D-FEATURE [(LAMBDA (X) (AND ...))] 
[RANGER INPUT-Z HIGH])) 
(sGEN (NOT (AND (> 30000 500) (< 30000 2000.0))) 
(D-FEATURE [(LAMBDA (X) (AND ...))] 
[RANGER INPUT-Z MODERATED) 
(sGEN (NOT (< 30000 1000)) 

(D-FEATURE [(LAMBDA (X) (AND ...))] 
(RANGER INPUT-Z LOU]))] 
0) 
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I The winning feature is "high input impedance": 

(RECORDING ID-FEATURE [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
(- (V-GAIN ...) 5) 
(- (INPUT-Z ...) 38088)))] 
[RANGER INPUT-Z HIGH]] 
8) 



;A similar deduction is done for the case of voltage gain: 

(RECORDING tO-SHARO [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
(= (V-GAIN ...) 5) 
(- (INPUT-Z ...) 38888)))] 
[(LAMBDA (X) (- (V-GAIN ?X) 5))]J 
8) 

(RECORDING (POS-CQ-SHARD [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
(- (V-GAIN ...) 5) 
(- (INPUT-Z ...) 38888)))] 
[X] [V-GAIN ?X] [511 
8) 

(RECORDING [POS-CQ-SHARD [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
(- (V-GAIN ...) 5) 
(- (INPUT-Z ...) 38888)))] 
[X] IS1" (V-GAIN ?xn 
8) 

(RECORDING (SIDE-TASK [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
(- (V-GAIN ...) 5) 
(- (INPUT-Z ...) 38888)))) 
[(LAMBDA (X) 

(CONSTRAIN <'...> (LAMBDA (Gl) (- ... 5) ) ) H ] 
8) 

(RECORDING [AND (:GEN (NOT (> 5 1888)) (D-FEATURE [(LAMBDA (X) 

(AND ...))) 
[RANGER V-GAIN VERY-HIGH])) 
(:GEN (NOT (AND (> 5 50) (< 5 5888))) 
(O-FEATURE [(LAMBOA (X) (AND ...))] 
[RANGER V-GAIN HIGH])) 
(:GEN (NOT (AND (> 5 1) (< 5 188))) 
(D-FEATURE [(LAMBDA (X) (AND ...))] 
[RANGER V-GAIN MODERATED) 
(:GEN (NOT (-< 5 D) (D-FEATURE [(LAMBDA (X) (AND ...))] 
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[RANGER V-GA1N LOU]))] 
8) 

(RECORDING [O-FEATURE [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
(- (V-GAIN ...) 5) 
(- (INPUT-Z ...) 38888)))] 

[RANGER V-GAIN MODERATE]] 
8) 



;The Ia9t d-shard gives us the core device type: 

(RECORDING [D-SHARD [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
(- (V-GAIN ...) 5) 
(- (INPUT-Z ....) 38888)))] 
[(LAMBDA (X) (DEV-TYPE ?X AMPLIFIER))]] 
8) ! 
(RECORDING (CORE -DEV-TYPE [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
(- (V-GAIN ...) 5) 
(- (INPUT-Z ...) 38088)))] 
[AMPLIFIER]] 
8) 
(♦INFERENCES DONE*) 

;This concludes the inferences of the exploder 

;Nou the other tasks of the rephrasing plan assemble the features, core 

; device type, and constraints into a new task network: 

(ENABLEO [FEATURES-FINDER PLAN0388] ) 
(ENABLED (CORE -FINDER PLAN#388) ) 
(EXECUTING [CORE-FINDER PLAN0388] 
(:FIND (LAMBDA (+DT) 

(CORE -DEV-TYPE [(LAMBDA (X) 

(AND ..))] 
?+DT))] 
[<' (CORE-DT PLAN0380) >] ) 
(TASK [CORE -FINDER PLAN#388] PRIMITIVE) ! 
(OLD TASK [MAIN-TASK-INFERER PLAN//388) 

HAS ACTION t: INFER '(AND (STASK (MAKER (*DES*) ) 

(*DES*) 
<> 

(LAMBDA NIL (MAKE (DEN ...))) 
<* (WINNER ...)>) 
(:MAIN (MAKER (*OES*)) 
(*DES*) ) ) 
<(C0RE-FIN0ER PLAN#388)>)) 
(ENABLED [MAIN-TASK- 1 NFERER PLAN#388] ) 
(FINISHED (CORE-FINDER PLAN#388] ) 

{Retrieval of the core device type enables the system to infer 
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l the main task: 

(EXECUTING [MAIN-TASK- I NFERER PLAN#380] 

I: INFER * (ANO (STASK (MAKER (*OES*)) (*DES*) 
<> 

(LAMBDA NIL (MAKE (DEN ...))) 
<* (WINNER ...)>) 
(:MAIN (MAKER (*DES*)) (*DES*)H 
< (CORE-F I NOER PLAN0388) >] 

(TASK [MAIN-TASK-INFERER PLAN0380J 

PRIMITIVE) 
(INFERENCES MADE BY [MAIN-TASK-INFERER PLAN#380) 

— ) 

(RECORDING [:TASK (MAKER (*DES*) ) <> (LAMBDA NIL (MAKE AMPLIFIER)) 
<* (WINNER (*DES*))>] 
8) 
(CREATING TASK t:TASK (MAKER (*DES*)) <> 

(LAMBDA NIL (MAKE AMPLIFIER)) 
<' (WINNER (.*DES*))>1) 
(RECORDING t:SUBTASK (MAKER (*DES*)) (*DES*)] 

0) 
(RECORDING I: MA IN (MAKER (*OES*) ) (*DES*)] 

0) 
(♦INFERENCES DONE*) ! 
;End of inferences by main task inferer 

(ENABLED [SIOE-TASKS-FINDER PLAM/3801 ) 
(FINISHED [MAIN-TASK-INFERER PLAN#3801 ) 
(BLOCKED [MAKER (*DES*)]) 

;Now the features of the desired device cause policies to be created: 
(EXECUTING [FEATURES-FINDER PLAN#380] 

[: INFER ' (FOR ALL (+FT) (-> G (D-FEATURE I...] ?+FT) 

(EXISTS (T) (ANO (STASK ...) 
(:SCOPE ...) 
(zSUCCESSOR ...))))) 
<>] 
[<>]) 
(TASK [FEATURES-FINDER PLAN#380J 

PRIMITIVE) 
(INFERENCES MADE BY [FEATURES-FINDER PLAN#380) 
— ) 

(RECORDING l:GEN (NOT (D-FEATURE [(LAMBDA (X) (AND ...))] 

?+FT)) 
(AND (STASK T! 400/1 1G5 (*DES*) 
<> 

(LAMBDA NIL (D-NOTE (DEN ?+FT))) 
<>) 
(: SCOPE T 1400/1 165 (MAKER (*DES*) ) ) 
(: SUCCESSOR T! 400/1 1G5 (MAKER (*DES*))))J 
0) 
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(RECORDING (:TASK TI400/1691 <> (LAMBDA NIL 

(D-NOTE (RANGER INPUT-Z HIGH))) 
<>] 
0) 
(CREATING TASK CtTASK T 1400/1691 <> (LAMBDA NIL 

(D-NOTE (RANGER INPUT-Z HIGH))) 
<>]) 
(RECORDING (rSUBTASK T 1400/1691 (*DES*H 
0) 

jNoting the SCOPE of the task triggers several rules for 
suggesting ways to make an amplifier: 

(RECORDING hSCOPE TI400/1691 (MAKER (*DES*))] 

0) 
(RECORDING ttANTEC (NOT hPOLICY TI400/1691 

(0-NOTE (RANGER V-GAIN MODERATE)))) 
(: TO-DO (MAKER (*DES*)) (MAKE AMPLIFIER) <?DEV*29> 
(MAKE CE))1 
0) 
(RECORDING I:ANTEC (NOT (:P0LICY TI400/1691 

(D-NOTE (RANGER V-GAIN HIGH)))) 
(: TO-DO (MAKER (*DES*) ) (MAKE AMPLIFIER) <?DEV~29> 
(MAKE N-STAGE))] 
0) 

(RECORDING t:ANTEC (NOT (:POLICY TI400/1691 

(D-NOTE (RANGER V-GAIN VERY-HIGH)))) 
(: TO-DO (MAKER (*DES*) ) (MAKE AMPLIFIER) <?DEV~29> 
(MAKE OP-AMP))] 
0) 

(RECORDING IrANTEC (NOT (: POL ICY T 1400/1691 

(D-NOTE (RANGER FREQ-OP VERY-LOU) ) ) ) 
(: TO-DO (MAKER (*DES«) ) (MAKE AMPLIFIER) <?DEV A 29> 
(MAKE DIFF-AMP))] 
0) ! 

(RECORDING ttANTEC (NOT (: POL ICY T! 400/1691 

(D-NOTE (RANGER INPUT-Z HIGH)))) 
(: TO-DO (MAKER (*DES*)) (MAKE AMPLIFIER) <?0EV*29> 
(MAKE CO) J 
0) 
(RECORDING ttANTEC (NOT hPOLICY TI400/1691 

(D-NOTE (RANGER P-GAIN HIGH)))) 
(AND (: TO-DO (MAKER (*DES*)) (MAKE AMPLIFIER) 
<?DEV~29> 
(MAKE COMP-SYM)) 
(:TO-DO (MAKER (*DES*) ) (MAKE AMPLIFIER) 
<?DEV~29> 

(MAKE PUSH-PULL) H] 
0) 

(RECORDING ttANTEC (NOT (:POLICY ?PTASK A 29 (MAKER (*DES*) ) 

(D-NOTE LINEAR))) 
(: TO-DO (MAKER (*DES*)) (MAKE AMPLIFIER) <?DEV~29> 
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(MAKE CE))3 
8) 
(RECORDING f: SUCCESSOR T 1408/1691 (MAKER (*DES*))1 

0J 

(RECORDING t:TASK TI488/2154 <> (LAHBDA NIL 

(D-NOTE (RANGER V-GA IN MODERATE))) 

<>] 
8) 
(CREATING TASK I: TASK T 1480/2154 <> 

(LAMBDA NIL (D-NOTE (RANGER V-GAIN MODERATE))) 
<>]) 
(RECORDING (:SUBTASK TI488/2154 (*DES*)1 

8) 
(RECORDING [t SCOPE T 1400/2154 (MAKER («DES*))1 

J 

;Similarly for this feature: 

(RECORDING ttANTEC (NOT (:POLICY TI488/2154 

(O-NOTE (RANGER V-GAIN MODERATE)))) 
(: TO-DO (MAKER (*DES*)) (MAKE AMPLIFIER) <?DEV~29> 
(MAKE CE))1 

0) 
;The 9ame rules will be found again (a slight non-opt imal i ty 

; in the phrasing of the these rules) 

• • • 

(RECORDING t:SUCCESSOR T!488/2154 (MAKER (*DES*))1 

8) 
(♦INFERENCES DONE*) ! 
;End of inferences by features finder. 

(FINISHED (FEATURES-FINDER PLAN#3801 ) 
(BLOCKED IT 1400/1691)) 
(BLOCKED (T 1400/2154]) 

;The side-tasks finder similarly turns side-task shards into CONSTRAIN 

(EXECUnNG [SIDE-TASKS-FINDER PLAN#380] 

I: INFER * (FORALL (+ST) (-> G (SIDE-TASK [...] ?+ST) 

(EXISTS (T) (AND (STASK ...) 

(:SUCCESSOR ...))))) 

<>] 

[<>]) 
(TASK [SIOE-TASKS-FINDER PLAN#388] 

PRIMITIVE) 
(INFERENCES MADE BY [SIDE-TASKS-FINDER PLAN#3881 

— ) 

(RECORDING l:GEN (NOT (SIDE-TASK [(LAMBDA (X) 

(AND ...))) 
?+ST)) 
(AND (STASK T 1481/6787 (*DES*) 
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0) 



<• (WINNER (*DES*))> 
(DEN ?+ST) 
<>) 
(: SUCCESSOR (MAKER (*DES*)) 
T 1401/6707))] 



(RECORDING t:TASK TI401/3406 <' (WINNER (*DES*))> 
(LAMBDA (X) 

(CONSTRAIN <*(V-GAIN ?X)> 
(LAMBDA (Gl) (- ?G1 5)))) 
<>] 
0) 
(CREATING TASK [:TASK TI401/340G <' (WINNER (*DES*))> 
(LAMBDA (X) 

(CONSTRAIN <*(V-GAIN ?X)> 
(LAMBDA (Gl) (- ?G1 5)))) 

(RECORDING (tSUBTASK T 1401/3406 (*DES*)1 

0) 
(RECORDING ^SUCCESSOR (MAKER (*DES«) ) 
T 1401/34061 

0) 
(* INFERENCES DONE*) 
$End of inferences by side-tasks finder. 

(ENABLED (GATHERER PLAN0380] ) 

(FINISHED [SIDE-TASKS-FINDER PLAN#3881 ) ! 

(BLOCKED [T! 401/34061) 

;The "gatherer" just marks the design task reduced: 

(EXECUTING (GATHERER PLAN0380] 

(.-INFER M:REDUCED (*DES*) ) < (CORE-FINDER PLAN0380) 

(SIOE-TASKS-FINDER PLAN0380) 
(FEATURES-FINDER PLAN#380)>1 

(TASK [GATHERER PLAN#3801 PRIMITIVE) 
(INFERENCES MADE BY [GATHERER PLAN03801 

— ) 
(RECORDING I: REDUCED (*DES*)1 0) 
(♦INFERENCES DONE*) 
; The interpreter will see this message in a second. 

(ENABLED [(*OES*)l) ! 
(FINISHED [GATHERER PLAN#3881 ) 

;Now the task is reattempted: 
(EXECUTING [(*DES*)1 [DESIGN (LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
(= (V-GAIN ?X) 5) 
(- (INPUT-Z ?X) 30000)))] 
[<' (WINNER) >1) 
(TASK t(*DES*)l ALREADY REDUCED) ;The /rREDUCED formula is seen 
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(ENABLED [TI400/1G91] ) 
(ENABLED [T ! 488/2154] ) 

;The policies are put into effect: 

(EXECUTING [T 1488/2154] (D-NOTE (RANGER V-GAIN MODERATE)] 

[<>]) 
(TASK (T 1408/2154] BEING REDUCEO) 
(TASK [T'400/2154] REDUCED TO t:PRIM *SETUP] ) ! 
(EXECUTING IT 1400/1691] [D-NOTE (RANGER INPUT-Z HIGH)] 

[<>]) 
(TASK [T 1400/1691] BEING REDUCED) 
(TASK [TI488/1691] REDUCED TO hPRIM *SETUP] ) 

;Recording these policies causes two of the rules inferred above to 
; fire. . . 

(ENABLED (MAKER (*DES*)]) 

(EXECUTING (MAKER (*DES*)] [MAKE AMPLIFIER] 

[<* (WINNER (*DES*))>]) 
(TASK [MAKER (*DES*)J BEING REOUCEO) 

; . . . so there are two ways, common emitter and common collector, 
; to make an amplifier 
(MAKING A CHOICE) 

(RECORDING I: CHOICE CHOICE0402 EXEC( 
t: TO-DO (MAKER (*DES*) ) 

(MAKE AMPLIFIER) <' WINNER (*DES*))> 
?UAY] ] 
0) 
; The system records first the choice, then the options. 
;Recordi'ng the choice causes a flock of choice rules to.be 
; instantiated: 
(RECORDING t:GEN (NOT (:= (MAKER (*DES*)) ?AMP-TASK~3) ) 

(AND (CHOOSE-AMP-PKT CHOICE#402 ?AMP-TASK A 3 

[MAKER (*OES*)] [' WINNER ...)3 [?UAY] ) 
(:GEN (NOT (: SCOPE ?PTSK~3 ?AMP-TASK"3) ) 
TRUE))] 
0) 

• • • 

; The choice rules come in a packet: 

(RECORDING [CHOOSE-AMP-PKT CHOICE0402 (MAKER (*DES*) ) 

[MAKER (*DES*H 

[' (WINNER (*DES*))] 

[?UAY] ] 
0) 
;This odd-looking formula is intended to trigger antecedent 
; rules in the packet which would otherwise not be noticed 
(RECORDING [:GEN (NOT (:SCOPE ?PTSK A 4 (MAKER (*DES*) ) ) ) 

TRUE] 
0) ! 
; ... such as this one: 
(RECORDING [:ANTEC (NOT (:SCOPE 7PTSK1 (MAKER (*DES*) ) ) ) 

(:GEN (NOT (AND (:POLICY 7PTSK1 (D-NOTE LINEAR)) 
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(: SCOPE ?PTSK2 (MAKER (*DES*) ) ) 

(: POL ICY 7PTSK2 

(O-NOTE (RANGER P-GAIN HIGH))) 

(=> '(DEN ...) 7PTSK2))) 

(:ANTEC (NOT (:OPTION CHOICE#482 ?A1 [:TO-00 ...])) 

. (:GEN (NOT (OPT-SUPPORT ?A1 ...)) 

(: RULE-TOGETHER <?A1>- [: TO-DO ...]))))] 
8) 

(RECORDING [: SCOPE T 1480/2154 (MAKER (*DES*))] 
8) 

(RECORDING t: SCOPE T 1488/1691 (MAKER (*DES*))1 
8) 

;Here is the first option 

(RECORDING hOPTION CHOICE0482 0PT#483 (: TO-DO (MAKER (*DES«) ) 

(MAKE AMPLIFIER) 

<* (WINNER (*DES*))> 

(MAKE COJ] 
8) 

; 1 1 f inds a rule 

(RECORDING t:ANTEC (NOT (rOPTION CH0ICE#482 ?A1 

ts TO-00 (MAKER (*DES*) ) 

(MAKE AMPLIFIER) <_?+N> 

(MAKE _?+DTl)])) 

(:GEN (NOT (OPT-SUPPORT ?A1 

(sPOLICY _?+PTASK (D-NOTE ...)])) 

(:ANTEC (NOT (: OPTION CHOI CE#482 ?A2 t:TO-DO ...J)) 

(:GEN (- ?A1 ?A2) ($ RULE-TOGETHER <?A1 ?A2> 

t: TO-DO ...]))).)] 
8) 

;and checks the support for (he options to see if input impedance 

5 was relevant 

(RECORDING t:GEN (NOT (OPT-SUPPORT 0PT#483 

[: POL ICY _?+PTASK A 3 

(D-NOTE (RANGER INPUT-Z _...))])) 
(:ANTEC (NOT (: OPT I ON CH0ICE#482 ?A2 A 3 

(: TO-DO (MAKER ...) (MAKE AMPLIFIER) 
<, . .> 

(MAKE _...)])) 
(:GEN (- OPT0483 ?A2 A 3) 

(: RULE-TOGETHER <0PT#483 ?A2 A 3> 

I: TO-DO (MAKER ...) (MAKE AMPLIFIER) <...> 
(MAKE ...)])))•] 
8) ! 
; I t wag 

(RECORDING (:ANTEC (NOT (: OPT I ON CHOICE0492 ?A2 A 4 

I: TO-DO (MAKER (*0ES*)) 
(MAKE AMPLIFIER) <'...> 
(MAKE _?+DT2 A 4)])) 
(:GEN (. OPT#483 ?A2 A 4) 

(: RULE-TOGETHER <0PT#483 ?A2 A 4> 
(: TO-00 (MAKER (*0ES*)) 

(MAKE AMPLIFIER) <*...> 
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(MAKE (CASCADE CC ...))]))] 
8) 

(RECORDING t:GEN (- 0PT#483 OPT0483) (: RULE -TOGETHER <0PT#483 0PT#483> 

[: TO-DO (MAKER (*DES*) ) 
(MAKE AMPLIFIER) 
<* WINNER ...)> 
(MAKE (CASCADE CC CO)])] 
0) 

;The rule excludes cascading something Mith itself, so this line of 
j inference dies. 

;Here is the second option: 
(RECORDING t: OPT I ON CHOICE0482 0PT#484 
C: TO-DO (MAKER (*DES*) ) 

(MAKE AMPLIFIER) <* (WINNER (*DES*))> 
(MAKE CE)]] 
8) 

?It is checked for input impedance being relevant 

(RECORDING I:GEN (NOT (OPT-SUPPORT OPT0404 [: POL ICY _?+PTASK"3 

(D-NOTE (RANGER INPUT-Z _ 
...))))) 
(:ANTEC (NOT (: OPT I ON CH0ICE#482 ?A2~3 

t: TO-DO (MAKER ...) (MAKE AMPLIFIER) 
<• . .> 

(MAKE _...)])) 
(sGEN (- OPT0484 ?A2 A 3) (: RULE -TOGETHER <0PT#484 

?A2 A 3> 
[s TO-DO (MAKER ...) 
(MAKE AMPLIFIER) 
<. . .> 

(MAKE ...)])))] 
8) ! 
;It isn't. However, the /:ANTEC derived from the other option 
; triggers, 

(RECORDING (:GEN ( = 0PT#483 0PT#484) 

(: RULE -TOGETHER <0PT#483 0PT#484> 
[: TO-DO (MAKER (*DES*)) 

(MAKE AMPLIFIER) <' (UINNER ...)> 
(MAKE (CASCADE CC CE))])] 
8) 
; and the appropriate cascade is suggested: 
(RECORDING [; RULE-TOGETHER <0PT#483 0PT#484> 

[: TO-DO (MAKER (*DES*)) (MAKE AMPLIFIER) 
<* (WINNER (*DES*))> 
(MAKE (CASCADE CC CE))]] 
8) ! 
(RECORDING [:OPTION CHOICE0482 NEU0PT#485 
t: TO-DO (MAKER (*DES*) ) 

(MAKE AMPLIFIER) <' (WINNER (*DES*))> 
(MAKE (CASCADE CC CE))]] 
0) 
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8 This new option goes through the mill also 
(RECORDING t:GEN (NOT (OPT-SUPPORT NEW0PT#485 

t; POL ICY _?+PTASK A 3 

(D-NOTE (RANGER INPUT-Z _...))])) 
(:ANTEC (NOT (: OPT I ON CHOICE0402 ?A2~3 

(: TO-DO (MAKER ...) (MAKE AMPLIFIER) 
<. . .> 

(MAKE _...)])) 
(:GEN (- NEWOPT0405 ?A2 A 3) 

(: RULE-TOGETHER <NEW0PT#485 ?A2 A 3> 

f: TO-DO (MAKER ...) (MAKE AMPLIFIER) 



8) 



(MAKE ...)])))] 



;A rather unpromising cascade is suggested: 

(RECORDING t:GEN ( = OPT0403 NEWOPT0405) 

(: RULE-TOGETHER <OPT#403 NEWOPT#405> 

(: TO-DO (MAKER (*0ES*) ) (MAKE AMPLIFIER) 

<' (WINNER ...)> 

(MAKE (CASCADE CC (CASCADE CC CE)))])] 
8) 

(RECORDING (: RULE- TOGETHER <OPT#403 NEWOPT#405> 

C: TO-DO (MAKER (*DES*) ) (MAKE AMPLIFIER) 

<* (WINNER (*DES*))> 

(MAKE (CASCADE CC (CASCADE CC CE)))]] 
0) 

jbut for some reason vanishes. (Notice that the rule should be, 
; "If k was suggested because of i ts input impedance and y wasn't. 
; cascade them." Then this cascade would never have been suggested.) 

;The /: RULE-TOGETHER causes the old options to be flushed 

(FLUSHED t:C0NSEQ (tOPTION CH0ICE#482 0PT#484 [:T0-D0 (MAKER (*DES*) ) 

(MAKE AMPLIFIER) 

<' (WINNER ...)> 

(MAKE CE)]) 
FALSE] ) 

(FLUSHED hCONSEQ (; RULE -TOGETHER <0PT#483 OPT#404> 

(: TO-DO (MAKER (*DES*)) 
(MAKE AMPLIFIER) 
<' (WINNER ...)> 
(MAKE (CASCADE CC CE))]) 
FALSE] ) 
(FLUSHED (:C0NSEQ (: OPT I ON CHOICE//402 OPT0403 

I: TO-DO (MAKER (*DES*) ) 

(MAKE AMPLIFIER) <' (WINNER ...)> 
(MAKE CC)]) 
FALSE] ) 
(FLUSHED [:ANTEC (NOT (: OPT I ON CH0ICE#482 ?A2 A 4 

f: TO-DO (MAKER (*DES*) ) 
(MAKE AMPLIFIER) <*...> 
(MAKE _?+DT2 A 4)])) 
(:GEN (- OPT0403 ?A2 A 4) 
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(: RULE-TOGETHER <OPT#403 ?A2*4> 
[: TO-DO (MAKER (*DES*) ) 

(MAKE AMPLIFIER) <'...> 
(MAKE (CASCADE CC _...)))) )J ) 
(FLUSHED hCONSEQ (: RULE-TOGETHER <OPT#403 NEUOPT#405> 

[: TO-DO (MAKER (*DES*)) 

(MAKE AMPLIFIER) <' (WINNER. ...)> 
(MAKE (CASCADE CC (CASCADE CC CE)))1) 
FALSE) ) 
(CHOICE CHOICE#402 DONE) 

jThe choice successfully reduced the design problem: 

(TASK [MAKER (*DES*)1 REDUCED TO [MAKE (CASCADE CC CEH) 
(CREATING TASK I:TASK G0248 <> (LAMBDA NIL 

(MAKE (CASCADE CC CE))) 
<' (WINNER (*DES*))>)) 
(NEW TASK IG0248) HAS ACTION [MAKE (CASCADE CC CE))) 
(ENABLED [G0248] ) 
(EXECUTING [G0248) [MAKE (CASCADE CC CE)J 

(<• (WINNER (*DES*))>J) 
(TASK [G02483 BEING REDUCED) 

;There is a standard plan for doing cascades: 

(TASK [G0248J REDUCED TO t: DO-SUBNET (CASCADE-PLAN CC CE) 

<CASCADE-NAME>) ) ! 
(CREATING TASK [:TASK (MAKER-1 PLAN#406) 

<> (LAMBDA NIL (MAKE CO) 

<' (FIRST-DEV PLAN#406)>]) 
(CREATING TASK [:TASK (MAK£R-2 PLAN#40G) 

<> (LAMBDA NIL (MAKE CE)) 

<• (SECOND-DEV PLAN#406)>J) 
(CREATING TASK [:TASK (GRABBER PLAN0406) <> 

(LAMBDA NIL 

(GRABBA (LAMBDA (X) 

(MAIN-DEV-TYPE ?X (CASCADE CC CE))))) 

<' (CASCADE-NAME PLAN0406)>1) 
(CREATING TASK [:TASK (COUPLER PLAN//40G) 

<' (FIRST-DEV PLANM06) * (SECOND-DEV PLAN#40G)> 

(LAMBDA (01 D2) (COUPLE ?D1 ?D2)) 

<>]) ! 

At this point a bug in the specification for the cascade plan caused the 
system to crash. (This would have been caught by a syntax checker of the kind 
I mentioned above.) In any case, the system currently lacks knowledge of 
common-collector circuits and constraint analysis, so it could not have gone 
much further. 



V Results 171 



V.B.2 Converting a Square Uave into a Sine Have 

In this section I present the someHhat more disappointing behavior of DESI 

on the job of converting a 1 kHz square wave into sine wave of the same 

frequency, expressed as follows 

(design 
(\ (ckt) 

(convert ?ckt 
(\ (in) 

(and (periodic (tfun ?in) 1.8E-3) 
(forall (t) 

(and (implies (/< ?t 0) 

(» ((one-period (tfun ?in)) ?t) 
1)> 
(implies (not (/< ?t 0)) 

(» ((one-period (tfun ?in)) ?t) 
-1))) )) ) 
(\ (in out) 
(« (tfun ?out) 

(\ (t) (sin (* 2888 pi ?t)) )) )) )) ) 
<' (filter)>l) 

;The initial part of the sequence is just as in Sect. V.B.I 
(CREATING TASK 

hTASK (*DES*) <> 
(LAMBDA NIL 

(DESIGN (LAMBDA (CKT) 

(CONVERT ?CKT (LAMBDA ...) (LAMBDA ...))))) 
<' (FILTER) >]) ! 
(ENABLED [(*DES*)]) 
(EXECUTING [ (*DES*) ] . . . ) 
(TASK [(*DES*)] BEING REDUCED) 
(TASK [(*DES*)] TO BE REPHRASEO) 
(CREATING TASK [:TASK (REPHRASER (*0ES*) ) 
<> 
(LAMBDA NIL 

(: REPHRASE (*DES*) (DESIGN (LAMBDA ...)) 
<MFILTER)>)) 
<>]) 
(ENABLED (REPHRASER (*DES*)1) 
(EXECUTING [REPHRASER (*DES*)] 

(: REPHRASE (*DES*) [DESIGN (LAMBDA (CKT) 

(CONVERT ?CKT (LAMBDA ...) 
(LAMBDA ...)))] 
<' (FILTER)>) 

(TASK [REPHRASER (*DES*M BEING REDUCED) 
(TASK [REPHRASER (*DES*)) REDUCED TO 
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[: DO-SUBNET (DESI-REPHRASE-PLAN 

[(LAMBDA (CKT) (CONVERT ...))] (*DES*) '(FILTER)) 
<>]) ! 

• • • 

;I have elided the messages regarding setting up the rephrasing 
; netuork. (They are the same as for the preceding example.) 

• • • 

(EXECUTING (ACCOUNT-FOR-ALL PLAN//3921 

[ACCOUNT-FOR-ALL-SHARDS 

[(LAMBDA (CKT) (CONVERT ?CKT (LAMBDA ...) (LAMBDA ...)))] J 

[<>]) 
(TASK [ACCOUNT-FOR-ALL PLAN#392) BEING REDUCED) 
(TASK [ACCOUNT-FOR-ALL PLAN0392] REDUCED TO [:PRIM *SETUP) ) 
(ENABLED [EXPLODER PLAN#392) ) ! 
(EXECUTING [EXPLODER PLAN03921 

[D-EXPLODE [(LAMBDA (CKT) (CONVERT ?CKT (LAMBDA ...) (LAMBDA ...)))]) 

[<>]) 
(TASK [EXPLODER PLAN#3921 BEING REDUCED) 

; Exp I os ion begins as before... 

(TASK [EXPLODER PLAN#392] REDUCED TO [t INFER ' (D-SHARD [(LAMBDA ...)) 

[(LAMBDA ...))) 
<>]) 
(INFERENCES MADE BY [EXPLODER PLAN03921 

— ) 
(RECORDING tD-SHARD [(LAMBDA (CKT) 

(CONVERT ?CKT (LAMBDA ...) (LAMBDA ...)))] 
[(LAMBDA (CKT) 

(CONVERT ?CKT (LAMBDA ...) (LAMBDA ...)))]] 
8) 

;But this time the main shard is too hairy to be handled by STP, 
; so a subtask is set up 

(RECORDING t:TASK Tl 1379/2344 <> 

(LAMBDA NIL (CVT-EXPLODE [(LAMBDA ...)] [(LAMBDA ...)])) 
<>] 
0) 
(CREATING TASK [:TASK Tl 1379/2344 <> 

(LAMBDA NIL (CVT-EXPLODE [(LAMBDA ...)] 

[(LAMBDA ...)])) 
<>]) 
(RECORDING [-.SUBTASK Tl 1379/2344 (EXPLODER PL AN0392)] 

8) 
(RECORDING hMAIN Tl 1379/24 (EXPLODER PLAN#392)1 
8) 

;The same rule <*CONVERT-EXPLODE> also sets up a rule to infer 
j SIG-TRANS d-shards from the "signal features" that fall out 
; of the convert explosion... 

(RECORDING [:ANTEC (NOT (SIG-FEATURE [(LAMBDA ...)] [(LAMBDA ...)] 

?+FEATURE~47) ) 
(D-SHARD ULAHBDA (CKT) (CONVERT ...))] 
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[(LAMBDA (CKT) (SIG-TRANS CKT ...))])] 
8) 

(♦INFERENCES DONE*) 

;Uork begins on this sub task 
(ENABLED [Tl 1379/2394] ) 
(EXECUTING [Tl 1379/2395) 

[CVT-EXPLODE [(LAMBDA (IN) (AND (PERIODIC ... 9.801) 

(FORALL ...)))] 
[ (LAMBDA (IN OUT) (- (TFUN . . . ) (LAMBDA ...)))]] 
[<>] ) ! 

(TASK [Tl 1379/23951 BEING REDUCED) 

;But there is a choice whether to look for frequency-domain 
; or time-domain features of the signals 
(MAKING A CHOICE) 

(RECORDING t: CHOICE CHOICER 10 EXEC 
t: TO-00 Tl 1379/4711 

(CVT-EXPLOOE I...] [...]) <> 
?UAY] ] 
0) 
(RECORDING hANTEC (NOT (.-OPTION CHOICE#410 ?A1~3 

[: TO-DO Tl 1379/4711 (CVT-EXPLODE ... ) 
<> 

(FREQ-DOMAIN-REPHRASE ...)])) 
(:ANTEC (NOT (: OPT I ON CHOICE#410 ?A2"3 
[: TO-DO ...1H 
(AND (:GEN (NOT (AND ...)) (: RULE-IN ?A1*3)) 
(:GEN (NOT (AND ...)) (:RULE-IN ?A2 A 3)) 
(:PEN (NOT (ANO ...)) 

(: RULE-OUT ?A2"3))))1 
0) 

(RECORDING [:OPTION CHOICE#410 0PT#4U t: TO-00 Tl 1379/4711 

(CVT-EXPLODE (...] 

[...]) 

<> 

(TIME -DOMAIN-REPHRASE [...] 

0) [ - ],1J 

(RECORDING t:OPTION CHOICE0410 0PT#412 I: TO-DO Tl 1379/4711 

(CVT-EXPLODE [...! 

[...]) 
<> 
(FREQ-DOMA I N-REPHRASE (...) 

0) 
(RECORDING [:ANTEC (NOT (: OPTION CH0ICE#418 ?A2 A 5 

(: TO-DO Tl 1379/4711 (CVT-EXPLODE ...) 
<> 

(T I ME-OOMA I N-REPHRASE ...)])) 
(AND (:GEN (NOT (AND (:=. ...) (NOT ...))) 
(: RULE-IN OPT0412)) 
(:GEN (NOT (AND (:- ...) (NOT ...))) 



Y Results 174 



(: RULE- IN ?A2 A 5)) 
(:GEN (NOT (AND (rSUBTASK ...) (: TASK-ACTION . ..) 

(:- ... ACTIVE) 

(D-FEATURE ...))) 
(s RULE-OUT ?A2 A 5)))] 



8) 



;The choice depends upon what the signal-descr ipt ion predicates 
; depend on. (See <*CVT-CHOICE> in Appendix 3.) 

(RECORDING t:GEN (NOT (AND (:» [...] [...]) (NOT (CONTAINS ?+B0DY~6 

...)))) 
(: RULE- IN OPT0412)] 
0) !!! 

; Frequency-domain is indicated — 
(RECORDING t: RULE- IN OPT0412) 8) 

(RECORDING tsGEN (NOT (AND (:- [...] [...]) (NOT (CONTAINS ?+B0DY~6 

...)))) 
(: RULE- IN OPTM11H 
8) !!!!!!!! 
The /:GEN found nothing in thi 9 case, so time domain gets no 
votes. 

(Checking CONTAINment took a long time, as the row of "!'s" 
attests. This is a typica.l example of the slowness of STP 
on a straightforward problem in which it did absolutely no 
combinatorial search.) 

;This rule also ended up with nothing: 

(RECORDING t:GEN (NOT (AND (:SUBTASK (DEN ...) ?SUP"6) 

(: TASK-ACTION ?SUP"G (D-EXPLODE ?+P A G) ) 
(: = (:ENAB-STATUS ?SUP^S) 
. ACTIVE) 

(D-FEATURE ?+P*6 [RANGER FREQ-OP VERY-HIGH]))) 
(: RULE-OUT 0PTM11)] 
0) 

;So the vote for frequency-domain is decisive... 
(CHOICE CHOICER 18 DONE) 
(TASK tTl 1379/2395) REDUCED TO 
[FREQ-DOMA I N-REPHRASE 

[(LAMBDA (IN) (AND (PERIODIC ... 8.981) (FORALL ...)))] 
[(LAMBDA (IN OUT) (- (TFUN ...) (LAMBDA ...)))]]) 
; . . . and execution proceeds 
(CREATING TASK [:TASK G8241 <> (LAMBDA NIL 

(FREQ-DOMA I N-REPHRASE [(LAMBDA ...)] 
[(LAMBOA ...)])) 
<>]) 
(ENABLED [G8241J) 
(EXECUTING [G8241)...) 
(TASK [G8241] BEING REDUCED) ! 
(TASK [G824U REDUCED TO 

t:SEQ (:FIND (LAMBDA (+FPT) 
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(EXISTS (FP1 FP2 FPT) 

(FORALL (SI S2) (IMPLIES ...))))) 

(LAHBDA (FPT) (j INFER ' (SIG-FEATURE ...) <>))]) 

: The plan is to find frequency pictures and compare them..., 
(CREATING TASK [:TASK ITASK#414 <> (LAMBDA NIL 

(:FIND (LAMBDA (+FPT) 

(EXISTS (FP1 FP2 FPT) 
(FORALL ...))))) 
<* (FPT#413)>]) 
; . . . then infer signal features. (See <*FREQ-DOM-REPH-DO-l>.) 
(CREATING TASK (:TASK MTASK0423 <MFPT#413)> 
(LAMBDA (FPT) 

(: INFER * (SIG-FEATURE ...) 
<>)) 

(ENABLED UTASK0414]) ! 

(BLOCKEO [MTASK#423J) 
(EXECUTING UTASK0414)...) 
(TASK [ITASK#414] PRIMITIVE) 

;/:FIND 19 the user's way of calling STP. 
;Here is what the STP trace looks like for this problem: 
(STP TRACE 1 (NOT (IMPLIES (AND (IS SIGNAL SI !433/3338) 

(AND (PERIODIC (TFUN ...) 
0.001) 
(AND (IMPLIES ...) (IMPLIES ...))) 
(IS SIGNAL S2 1434/3339) 
(- (TFUN S2 1434/3338) 
(LAMBDA (T) 
(SIN ...)))) 
(AND (.> ' (FREQ-PICTURE ...) 
?FP1) 
(=> ' (FREQ-PICTURE ...) ?FP2) 
(FREQ-PIC-TRANS ?FP1 ?FP2 

?FPT) 
(-> '(DEN ...) ?FPT)))] 
NIL) !!!! 

Unfortunately, a bug in a very low-level routine caused an infinite 
recursion in the mid9t of this attempted proof. Therefore, the system never 
got to the point of actually generating or comparing frequency pictures. 
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V.B.3 NOAH in NASL 

Jon Doyle and I have done some preliminary experiments toward a "free 
translation" of Earl Sacerdoti's (1975) NOAH program into NASL. As I 
discussed in Chapter I, NOAH and NASL are based on rather different 
presuppositions, so an exact translation Mould be somewhat contrived. NOAH is 
organized around repetitive execution of a strict sequence of steps of the 
form, "Expand the plan; criticize it." After the plan has been entirely 
reduced to primitives, it is executed. In carrying out these steps, the NOAH 
system assumes that all actions' effects are fully computable in advance; it 
reasons confidently about future states of the world. This assumption is 
false for many of the actions NASL tries to accomplish. 

Nonetheless, the parallels between the two systems are tempting. Ule 
uondered if it was possible to encode NOAH "critics" as NASL "policies." The 
critics we concentrated on were "Resolve Conflicts," which orders actions to 

« 

prevent one from undoing the prerequesi tes of another; and "Eliminate 
Redundant Preconditions," which attempts to prevent the same action being done 
twice for two different reasons. 

He have done some preliminary coding (it only takes about 5 page9 of NASL 
expressions), but the unsettled state of the interpreter has made this mainly 
a Gedanken experiment. The results so far are mixed. On the one hand, it 
takes very little effort to express as deductive "mini-theories" much of what 
is meant by concepts like "prerequisite" in a system like Sacerdoti's which 
has them bui I t in. 

On the other hand, we had some disappointments. It is more difficult than 
I had hoped to distinguish problem reduction from execution. NASL assumes 
that a network can be executed as soon as it is generated; to force it to be 
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on 



more NOAH- 1 ike requires the user to write explicitly the theory of elaborati 
levels that is apparent I y bui 1 1 into the NOAH elaborate-cr i tic ize loop. The 
user must explicitly tell the system to postpone execution of lower levels 
until higher levels are reduced. In principle, there is nothing wrong with 
having to do this, since this is just another mini-theory. What made us a bit 
squeamish about it was the necessity of ignoring altogether NASL's use of 
/:MAIN ta3ks (Sect. I I.B.I) in specifying what happens during task reduction, 
and replacing it with an explicit theory of /SUCCESSOR relations. 

I think it is fair to conclude from this "experiment" that NASL is an 
worthwhile alternative to NOAH, especially for problems where there is much 
user-supplied knowledge about plans, and only incomplete foreknowledge of the 
effects of the basic actions. 
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VI Conclusions 

"This ... may seem trivial, 
but I think it is not without importance." 

— Mary Uarnock, Ethics since 1900 

I 9et out to construct a circuit designer so flexibly organized that it 
could respond to all relevant aspects of a design problem, yet directed enough 
to be efficient during its normal operation. I implemented a rule-based 
problem 9olver called NASL and have done preliminary experiments using as my 
main vehicle DESI and ZORCH, sets of rules embodying theories of design and 
electronics. The results are consistent with the hypothesis that the 
organization of NASL has the right kinds of pouer. As uith many experiments 
in AI , the results are not unequivocal. Our conclusions rest largely on 
esthetic considerations. 

The theories of design and electronics drew heavily on previous work by 
others. (Freeman and Newell, 1971, Stal Iman and Sussman, 1976. A. Brown, 1975) 
There are novel elements. The design process embodies a modified top-down 
strategy. Domain-dependent information, expressed in a modular way, orders 
design choices and controls their interaction. Uhen the top-down elaboration 
reaches the level of canned "device schemata," the task structures stored 
there become integrated with it. The theories embodied in the programs that 
make this happen are further steps toward competing with human performance in 
these areas. 

NASL has severe limitations. Due to limited time, I uas unable to develop 
many domain- independent control features, because they were not needed for 
electronic design. (Some of these limits were encountered in our attempt to 
study NOAH with NASL. See Chapter V.) The logics of time and belief are 
practically absent. Hence, I cannot claim that the current system could be 
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ju9t as easily used, e.g., to understand stories. Even some features 
important to electronic design, such as describing and correcting mistakes. 
could not be implemented in the time I had. 

Second, the system's flexibility in principle is offset by its lack of 
patience and skepticism in assimilating what it hears. An untrained user 
could bring its operation to a halt by telling it the wrong things. 

I have had some disappointing failures. The program is too big and si on 
to be practical, apparently because of the implementation of data-base 
operations, rather than because of any combinatorial explosion. More 
substantively, the division of labor between theorem prover and interpreter is 
in many ways wrong. The decision to use predicate calculus for representing 
and using knowledge was the major theoretical gamble in NASL's design. This 
gamble has had wildly equivocal results. 

The style of knowledge encoding encouraged by NASL is, in my opinion. 
quite exciting. These features in particular stand out: 

> All control information is explicitly represented in the data base. 

> Host dependency information is automatically gathered by the system in a 
complete and convenient way. 

> Plans can be described incrementally. Specification of order and choice 
depends on rules which can be combined in flexible ways. 

> Predicate calculus is used as the notation for control and physical 
information. 

I will discuss first my successes, then my failures, and which way 
research might go to overcome the limitations I have discovered. 
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VI .A Successes 

In this section I want to put the NASL system in perspective, and argue 
that it is a step toward understanding mental functions. Fig. VI. 1 shorn a 
map of current art i f icial -intel I igence research. It may also be taken as a 
map of mental functions, with the arrows taken as indicating the flou of 
information. Either way, the central box with the question mark is a major 
mystery. Ue know that this center is concerned with "understanding," "problem 
solving," and "learning," and we know that it contains many sub-boxes. Much 
of mainstream AI is concerned with the somewhat speculative pastime of 
proposing and testing pieces of this box. 
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VISION 




Figure VI. 1 Provinces of Artificial Intelligence 
The thesis that rule-driven problem solving is an important technique 
depends, I think, on a picture of the mystery box like that of Fig. VI. 2. 
Normal cogitation is performed by a problem solver accessing a data base of 
rules. New rules are created by a rule generator; the most direct way is by 
translation from natural -language statements. The rules are not guaranteed 
"correct"; they must be revised if faulty by a debugger. (McDermott. 1974a, 
Sussman, 1975) 
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Figure VI. 2 The Rule-Ba9ed Utopia 

To 3ome degree, putting these last two functions in neat boxes 19 wishful 
doodling, but the problem-solver box '19 intended to be real. The NASL system, 
or 9ome future descendent, resides in th'19 box. To what degree do features of 
NASL support progre9s on the rule-driven paradigm? In answering this 
question, I will survey in detail what I con9ider the 9trength9 of the current 
system. 

NASL is driven by a general predicate calculus that supports backward and 
forward deduction. This feature forces the user to think in terms of truth 
and falsehood, rather than in terms of, e.g., "demonic action." For example 
(see Chapter II), there i9 no way to "deduce the erasure" of a formula. 
Unlike a PLANNER-type system (Hewitt, 1972), NASL treats erasure entirely 
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differently from recording. This enables more revealing records to be kept. 
It forces the user to think in terms of true rules rather than apparently 
useful ones, like productions, which might have to be changed later, or might 
introduce arbitrary symbols with no presumed meaning. (Rychener, 197G, Newell, 
1971) Thi9 half of Minsky's (1974) "monotonici ty" problem is no problem at 
all, but a valuable kind of d i sc i p I ine. 

The notational power of the predicate calculus strikes me as a tool we 
cannot do without. Much of this power depends on providing a good vocabulary; 
and, in the realm of control structure, I have done this. But the notation 
itself is good, in my experience, independently of what it is talking about. 
It allows you to think in terms of statements with truth values, its treatment 
of quantifiers doesn't cramp your style, it provides powerful and natural 
pattern matching, and it forces you to say what you mean. 

Thi9 formal freedom is necessary to to support restrictions on the 
substance of rules. NASL formulas are not restricted to talking about 
clinical parameters or values of physical quantities in a network, but they 
are restricted (for practical purposes) in the way they talk about concepts 
like action, decision, policy, and problem transformation. In order to get 
something done in NASL, you must express yourself in terms of tasks, "rule-ins 
and rule-outs," rephrasing actions, etc. The task language is restricted to 
9uch a degree (there being no real loops, gotos, or conditionals) that many 
things can be done only via these mechanisms. 

These conventions enforce "intelligibility" at a useful level. At every 
step, the system knows by way of quite shallow deductions almost everything 
there is to know about what it is doing, what its future tasks are, why it 
chose to do what it did, etc. This knowledge is used heavily in the rules for 
choosing, rephrasing, and mistake correction. Because the number of innate 



VI Conclusions 184 



concepts has deliberately been allowed to grow, shallow deductions are 
possible and required; NASL does not have or need a theory of "program 
understanding." (Ualdinger and Levitt, 1974) I believe this property is 
essential to an intelligent program; it is no accident that the average person 
is a good planner and a bad programmer. 

A most important example of this reliance on innate control concepts is 
the notion of "frozen tasks" which is so useful in the representation of 
device schemata. (Chapter III) The instantiation of such a schema causes 
information regarding the purposes of components to be activated, in the same 
notation that is used for expressing explicit goals. These old tasks then 
interact with new ones in determing the solution. In this way, DESI exhibits 
"machinomorphi sm. " The purpose of a circuit is expressed as a frozen purpose 
of the machine. No new concept needs to be introduced, and the problem of 
relating the special -purpose teleology of each domain to the machine's concept 
of its own purposes is avoided. 

This organization of predicate calculus plus large innate vocabulary is 
potentially of great value to the Rule Debugger module of Fig. VI. 2. It is 
known that debugging a data base requires keeping records of the use of data 
which might be faulty. (flcDermott, 1974a, Davis, 197G) The kinds of records 
kept by NASL, deductive dependencies and task relations, are just the kinds 
required. 

Another powerful organization principle that emerged during this research 
was the notion of "packet." (flcDermott, 1975) This device enables NASL to 
represent large chunks of data at a relatively low cost. It is used to 
represent circuit diagrams and sets of related problem-solving rules. 

From a distance, a packet looks like a large chunk of knowledge; up close, 
it looks like many small pieces of knowledge. It may be used to implement 
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"frames" (Minsky, 1974) in an "extensible" May. The knowledge is organized by 
the dependencies I described before, but a new piece of knouledge can always 
be added without immediate fear of interactions. 

This is partly because NASL is organized around the expectation of 
interactions. It expects that occasionally more than one or less than one 
rule will appear relevant. In these circumstances, it enters special 
protocols which first look for relevant higher-level rules, and then ask the 
user to supply them. Much remains to be done in this area. (Good work has 
been done already by Davis (1976).) The results so far indicate that the 
standard feeling that frames' contents are hopelessly "strongly coupled" (cf. 
Sussman, 1975) is too pessimistic. 

The fact that NASL's facts come in large chunks of small data has 
implications for the design of the Rule Generator of Fig. VI.2. It is a very 
appealing model of learning by discovery that large bites of information are 
taken at one time, by copying an entire theory from one domain to another. 
(Minsky, in progress) Uhat is nice about rule-based theories in particular is 
that they hint at the next step: altering particular rules that were faultily 
transformed during the "copy," and adding domain-specific interaction 
handlers. 

The kind of chunking that NASL currently supports would not handle this 
kind of learning, but it is suggestive. It might be worth making the effort 
to recast the entire corpus of electronics information as an instantiation of 
a more abstract (and smaller) theory of. say, common-sense physics. If this 
were successful, a start at capturing any similar domain would be to 
reinstantiate this theory in a different way. 

The conclusions I have drawn so far can be summarized as follows: (1) A 
flexible problem solver must have innate concepts of tasks, decisions, and 
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other simitar control concepts; (2) predicate calculus is, at present, the 
best language for expression of propositions in these terms; (3) the rules 
expressed in the calculus mu9t be tightly organized, linked by dependencies 
and bundled into packets. 

VI, B Fai lures 

The next questions are somewhat independent; Is a predicate-calculus 
theorem prover an effective mechanism for retrieval of information expressed 
this way? In particular, can it be interfaced effectively with the 
interpreter that uses it to decide how to act? Uith respect to these 
questions, the current version of NASL fails to provide satisfying answers. 

As it stands now, NASL is organized as follows. (See Fig. 1.9.) Control 
resides in the interpreter, which decides what to do and how to do it on the 
basis of (a) forward deduction triggered by plan and model assertions in the 
data pool; (b) backward deduction to find ways of breaking problems down and 
to answer questions in the domain of interest; (c) calls to the choice 
protocol, which consists of a ritual of deductions regarding uhich 
alternatives are good and which bad; and (d) calls to itself recursively with 
/: REPHRASE tasks (which are restricted to being inferential). The outstanding 
features of this organization are: 

(1) The action system always calls the theorem prover, never vice veria. 

(2) The system contains, in effect, two independent interpreters, one for 
plans, and one for implications (/:C0NSEQ's and /:ANTEC's). 

These features distinguish NASL rather sharply from the typical AI languages. 

(Bobrow and Raphael, 1974) 

The strengths of this organization are easy to see. The two interpreters 
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are optimized separately. For example, the theorem prover does not have to 
worry about 9ide effects, 90 it can re-order conjunctive goals and separate 
goals into classes which share variables for backtracking purposes.. (Sep 
Appendix 4.) The interpreter, on the other hand, does no backtracking at all; 
handling a failed action is a problem for the interpreter, not part of its 
solution mechanism. It goes to great trouble to find reasons for its choices. 
rather than ju9t trying one alternative now, and another later if that one 
fat Is. 

These strengths are pleasing, but they do not outweigh the weaknesses. 
which are: 

(1) The same knowledge must sometimes be put in two places, in two 
notations, one for each interpreter. 

(2) The deduction machinery is unable to use information about choice and 
rephrasing. 

(3) Additivity suffers from the user's uncertainty about which interpreter 
to use. If he guesses wrong, he may have to reorganize his data completely 
when the chickens come home to roo9t. 

Consider, for example', the notion of equation solving. DESI has a weak 

ability to do this (see Appendix 2 and Chapter III), which could be stronger 

without too much effort. Notice that this information has been expressed as 

an "inferential plan" concerned with rephrasing manipulations of predicates on 

constrained quantities. This seems entirely proper, clear, and elegant. Now 

consider the following deductive goal: 

t- (+ ?X 3) 5] 

Plainly, this requires exactly the same knowledge. (Cf. Bundy, 1975) 

It would be embarrassing enough to have to put the same information in two 

places, but in fact the situation is even worse: the necessary knowledge 

cannot be given to STP at all! (Which is uhy it appears in an inferential 

rephrasing plan.) It would have to be put into an ad hoc LISP program. 
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Rather than do this, I have tried to make sure that deductive goals of this 
sort never appear. The absence of a choice protocol inside the theorem prover 
hurt9 ju9t as much. The most embarrassing consequence of this awkwardness is 
that the user must plan his advice a little more carefully than is desirable; 
he must decide what should be expressed as a task and what should be expressed 
a9 a deductive goal on the basi9 of his knowledge of the theorem prover's 
limitations; this requires an unacceptable degree of knowledge of the 
program' 9 internal structure. 

This problem evolved from seemingly innocuous beginnings; what started as 
a 9ingle interpreter fissioned. It has been clear from the start of this work 
(flcDermott, 1974b) that the concepts of deduction and action were both going 
to be necessary. As design and implementation proceeded, these two categories 
became more and more closely identified with the independent categories of 
"blind search" and "careful mode," respectively. The theorem prover was 
written with fewer and fewer "careful" features, and more and more general 
optimization of the sort described above, while the action system absorbed the 
cleverness. This organization finally broke down when I realized that several 
sorts of "clever" forward deduction, such as constraint resolution (Stallman 
and Sussman, 197G), would not fit into the framework of a stupid theorem 
prover (STP) . The inferential plan was created to fill this gap. It may turn 
out to be the right solution (see below), but if it does it will be an 
accident. 

To 9ome degree this failure is due to sloppy thinking, but I believe the 
problem is more fundamental. The only way to make "careful mode" work is to 
9pend time asking and telling yourself what you're doing. If this asking and 
telling is itself "careful," things become intolerably slow. 

It might look as if asking and telling could be potentially careful, in 
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the sense that they could normally proceed blindly, but, if trouble arises, 
turn themselves into ongoing pi an- language plans. For example, with the 
conjunctive goal [AND (P ?X) (Q ?X)], if the system "runs into trouble" on [Q 
?X] , it could turn itself into a plan of the form "Find a P; then verify it is 
a Q, " and use choice and rephrasing on the second subtask. There are tuo 
problems with this. First, it is not all that easy to decide that you're in 
trouble. The mere retrieval of tuo rules, does not mean that a choice is in 
order; the two rules could be functioning as a COND, or there may be no 
intelligent criterion for selecting one or the other. Indeed, once one has 
the notion that the theorem prover is the locus of "b I ind search, " he t^nds to 
write rule systems of just this sort. However, I believe that the "meta-rule" 
construct of MYCIN (Davis et. a?., 1975) would go far toward solving this 
problem cheaply. 

Second, and much more difficult, is that the kind of sequencing done in a 
backtracking theorem prover is just not the same as that in a planner. 
Predicate calculus is a non-deterministic language; it does no good to 
translate it into a formally isomorphic construction in a deterministic 
language. Put another way, NASL is intelligible because many unintelligible 
constructs have been covered by deduction or other built-in protocol: "map" 
loops like those in LISP are done by generating items deductively and 
generating a (sub) task for each; many search loops are done by finding one 
9uch item; the choice protocol is a priceless piece of "canned loop" which 
replaces specialized discrimination nets. To ask that any of these constructs 
be translatable when necessary into NASL plans is to destroy this 
intelligibility. 

The situation is not hopeless; I have just learned less about this aspect 
than I had hoped. Here are two possible routes for avoiding this problem: 
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(1) Elevate this disorganization to the status of a theoretical conjecture 
that "deductive information retrieval" is a separable activity that never 
requires anything as complicated as solving an equation or rephrasing a goal. 
(This is part of what R. tloore (1975) and Fahlman (1975) have been urging.) 
Inferential plans Mould be retained for these complex tasks. 

(2) Provide deductive protocols analogous to those used by NASL. Dispense 
with inferential plans. This will require careful identification of 
situations where the protocol would be worth it (such as: choosing among 
answers to a conjunctive goal, ordering conjuncts, choosing splits, ordering 
implications to apply); and a way of efficiently noticing when there are no 
applicable rules, in which case brute-force deduction is to be used. 

The substantive difference between these alternatives is that alternative (1) 

makes complex inference a kind of task, and hence deterministic, saving search 

for the 3tupid theorem prover; while alternative (2) makes even complex 

inference subject to backtracking, which is modified by the application of 

rules. 



VI. C Further Work 

Let me list, in order of increasing difficulty, projects that are worth 
doing to extend this research. Some of them I may do myself. 

(1) Encode more electronics knowledge. The gaps in ZORCH are described at 
the end of Chapter III. 

(2) Speed the system up. The system can undoubtably be made much faster 
by abandoning some of my more elegant programming techniques. 

(3) Implement the error-handling machinery I described in Chapters II and 
III. This will require careful reconsideration of data dependencies. 

(4) Unleash the logical calculus. There are restrictions on NASL's 
generality which I believe are due mainly to inadequate implementation of the 
logical calculus. There are many domains which are beyond its grasp because 
it lacks a notation for things like time, belief, and the actions and beliefs 
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of other people. To some degree these areas could be handled by the use of 
modal reference points for time intervals and other people's minds. The 
system could simulate other persons' thought processes with its own theorem 
prover, and avoid some of the problems associated with epistemic logic. 
(Hintikka, 19G2) Broadening the syntax of V:TASK" to include an agent slot 
would be a step toward representing other persons' purposes; the interpreter 
could use itself to simulate them as a way of understanding their actions. 
(Cf. flcDermott, 1974a) However, there is an "abductive" component to such 
reasoning (Pople. 1973, Schank, 1975, Lehnert, 1975) that is beyond the 
capability of NASL without more substantive revision. 

(5) Endow the system with more "patience and skepticism." The greatest 
weakness of NASL as it now stands is its credulity. It accepts wrong rules 
(even syntactically wrong ones) as readily as right ones. This is 
unsatisfactory for a system which already understands its domain thoroughly; 
surely one task it should be able to carry out is to estimate the plau.sibi I i ty 
of a new rule in the presence of its old ones. 

In some simple cases, a new formula may be disproved. In that case, the 
syftem would be in an excellent position to claim that something was wrong. 
Unfortunately, this is not likely to happen very often. The less important 
reason for this is that STP is not built to do interesting proofs. The more 
important reason is that many theorems have conclusions defined only 
pragmatically, by their meaning to the NASL interpreter. These are the 
formulas of the form "Al and A2 and ... and Ak imply C," where C is in terms 
of concepts having to do with choosing (e.g., "^RULE-IN") or acting (e.g., 
"/:TASK"). These concepts are in a sense primitive; we want to define "good" 
and "feasible" in terms of these concepts rather than vice versa. Thus, I 
said that t/:TO-DO |task| |action| |outputs| |method|] meant, among other 
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things, that the method was an effective, feasible, and permitted way of 
carrying out the task. But, since there is no independent theory of ther^e 
concepts, a /:T0-D0 implication cannot, except in the most trivial ca<-.e<5, be 
disproved by showing its method uould not be permitted (or feasible or 
effective) under the circumstances. Still another problem is that a typical 
conditional of this sort is counter factua I ; one of the antecedents is probably 
false at the time the rule is heard, making a proof trivial. To disprove this 
rule, the system would have to prove a modal theorem to the effect that "there 
exists a 'possible world' in which the antecedents are true and the consequent 
false." 

The solution to these problems is to integrate the theory of action 
failure with the theory of assimilation of new information. In the early 
stages, this will be probably require the co-operation of a human friend. 
(Shortliffe, 1976) The idea is to place a new formula or set of formulas on 
"probation." (flcDermott, 1974a) Uhen a contradiction, action failure, or 
inability to choose occurs, the system will check the formulas involved to see 
which are on probation and might contain errors. The idea is to see how 
things would work out differently if the formula were not there. If, for 
example, a choice fails because all alternatives are eliminated, and there is 
a formula on probation involved whose absence would have left some 
alternatives in, the system is justified in asking for clarification of the 
new rule. 

Notice that this requires an "advice-taking protocol" for each clas^ of 
rules, that is, for each pragmatic predicate the system knows. It would be 
attractive if these were plan networks; and if the advice-taking actions in 
certain circumstances could be framed as policies. 

(G) Add a natural -language interface, this is difficult in itself, and. 
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Appendix 1 -- NASL Syntax and Informal Semantics 

A formula is an S-expression enclosed in [brackets]. Redundant 
parentheses may be dropped. Thus t(IS RESISTOR R#21)l is written [IS RESISTOR 
R02U . 

The leftmost element of a formula or 9ubpattern is its function. Functions 
with range ftrue, false) are predicates. The Boolean functions AND. OR. 
IMPLIES, and NOT operate on truth values. 

Besides functions and their arguments, there are "variable binders" whose 
job is to indicate the names and uses of variables in formulas. These arp the 
universal quantifier FORALL. the existential quantifier EXISTS, and LAHBOA, 
which defines functions and is used for all other variable-binding chores. 
(Lambda may be typed as "\" ("backslash") to my LISP system. I will us? this 
symbol instead of "V throughout the appendices.) Thus thp following are NASL 
expressions: 

[FORALL (X) (EXISTS (Y) (LOVES ?X ?Y))1 
[FORALL (X) (SATISFIES ?X 

(\ (Y) (EXISTS (Z) (P ?X ?Y ?Z) )))) 

Variables are flagged with a "?" where used, but not where bound. 

Many variables are not bound at all. As in most predicate calmlus- 
oriented systems, all formulas are Skolemized (Nilsson, 1971) before being put 
in the data base, so that there are no quantifiers at the "top level" of an 
expression. (Expressions remain quantified inside lambda expressions and as 
arguments to function.) Free (universally quantified) variables remain 
prefixed with a question mark. A "skolem form" represents an existent ia I ly 
quantified variable. Skolem forms look like 

[SK |var| |id number | -dominating uni versals-1 . 

For example, [FORALL (X) (EXISTS (Y) (LOVES ?X ?Y))] is internal ly repres-?nted 
as [LOVES ?X (SK Y 70 ?X)] : while [EXISTS (Y) (FORALL (X) (LOVES ?X ?Y))] is 
represented as [LOVES ?X (SK Y 71)]. The program generally abbreviates the 
general skolem form to " |var| ! | id number | " on output; e.g., (SK Y 70 ?X) is 
printed Y!70. I occasionally use this loose notation. (To avoid collision, a 
hash number derived from the skolem-form arguments is usually printed 
following the variable.) 

Because quant i fiers are retained inside lambda expressions, the example of 
a lambda expression above is skolemized to 

[SATISFIES ?X (\ (Y) (EXISTS (Z) (P ?X ?Y ?Z) ))] 

An important concept in predicate-calculus systems is matching, or 
unification, of two formulas. (Robinson, 19G5) Two formulas are said to match 
if there is a substitution for their variables which makes them equal. The 
variables are to be imagined subscripted with the name of the formulas they 
came from, to avoid confusion. Thus [P ?X (F ?V)] matches [P (F ?X) ?X) with 
the substitution 

Xj -♦ [F (F 7V],)] 
X 2 - [F ?V 1 ] 
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Internally, substitutions and subscripts are handled using a method derived 
from (Boyer and Moore, 1372). (See Appendix 4.) 

There are two special cases of matching. Fj subsumes F z , i f F £ i s equal 
to the result of performing a substitution on F v Fj and f £ ar e variants if 
they subsume each other; alternatively, if renaming the variables of F, makes 
i t equal to F~. 

These concepts are essential to the operation of the deductive system. 
(Appendix 4. ) 

The matcher is not intended to be a complete unification algorithm for 
nth-order logic, typed X-calculus logic, etc. A lambda expression will match 
another lambda expression if their variables differ only in name. Of course, 
free variables may not become bound to fragments of lambda expressions 
containing bound variables. Thus [P (\ (X Y) (F ?X (G ?Y)))] uill not match 
tP (\ (U V) (F ?U ?U))J. The matcher uill not create lambda-expressions 
without prodding. (See below.) Thus, [?F A] doesn't match tG (HA A)) with F 
- [\ (X) (G <H ?X ?X))] or any of the alternatives. 

The language allows formulas to refer to other formulas. Thus [ABSENT 
[BROUN C0U#22)] expresses a property of [BROUN COU022) . This is one of two 
ways in which NASL expressions may refer to other expressions. (It may be 
considered equivalent to. but more convenient than, the use of Goedel numbers 
of formulas.) It has the following variants. First, every user-defined 
cSr»«on h3S a ° atomic name - (See the description of OEFMLA in Appendix 2. ) I f 
FMLA#39 is the name of [BROUN C0U#22I , we may write [ABSENT FMLAtf33) . Second, 
an embedded formula may have variable parts, called escape Forms, which am 
prefixed by "_"; this indicates that the value of the prefixed expression 
(which should be a formula) is to be used to construct the formula. For 
example, if FUN is a function that maps a formula into its first subformula, 
[F00 [BAR _(FUN [F A])]) - [F00 [BAR F] ] . Escape forms are most useful in 
ocM. J A nCti ° n " ith variab ' es - T hus [F00 [BAR _?FMLA]] says, "For all formulas 
(^riLA, the formula obtained by making the pattern of ?FMLA the argument of BAR 
has property F00. " (Each such embedded formula is equivalent to some open 
term, such that substituting Goedel numbers for its free variables gives o 
closed term whose value is a Goedel number.) 

Matching embedded formulas against formulas with escaped variables is a 
way of decomposing formulas. This is used by some of the "meta-systems" of 
NASL. For example, the result of matching [P [F00 _?X1] against IP [F00 BAR]] 
is the substitution X -» [ [F00 BAR]]. 

For ease of manipulation of formulas, the primitive function DEN is 
understood by STP to map formulas onto what they denote. Thus [DEN [+5 5]] - 
1+5 5]. One convention I use is that variables ranging over formulas start 

Vcnm the T CharaCter " + " ; thU3 ?+X might des ''g n ate I IFOOJ J and ?X designate 
IFOOJ . This is purely a convention and not part of the language. 

Notice that all NASL formulas in this paper are surrounded by [brackets]. 
For example, in the result of matching [P ?X] against [P (F00 BAR)]. I write. 

?X has value tFOO BAR]," even though ?X was originally matched aqainst a 
subpattern without brackets. This enables you to tell unambiguously whirh 
formulas are being used and which quoted. (Actually, when it comes" to atomic 
symbols, I rarely make the distinction between a symbol and a formula. I 
allow myself to drop the brackets in a formula like [F001 . ) 

The "sense" construct using single quote is the second way in which NASL 
expressions may refer to other NASL expressions. It allows one to refer to 
the meaning" of an expression and not its value. For example, even if. the 
value of [- NIXON PRESIDENT] is false, [POSSIBLY ' (. NIXON PRESIDENT)] may be 
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true. 

Substitution of equals is, of course, prohibited inside any embedded 
formula or sense. 

The operator POSSIBLY is an example of a modal predicate. (Hughes and 
Cresswell, 1972, Bressan, 1972) The basic system-supported modal operator i9 
IT |reference-point | |pattern|], meaning the value of pattern in "possible 
world" reference-point. (Prior, 19G7) The second argument is implicitly 
quoted. Thus [T (1970) PRESIDENT) would have value NIXON; and [T (1970) U 
NIXON PRESIDENT)) would have value true. 

NASL contains tuples like those of QA4 (Rulifson et. al., 1972). They are 
represented using <angle brackets>. Uithin a tuple, the prefix "!#" moons 
that the value of what follows is to be considered spliced in instead of 
substituted directly. Such an expression is called a segment Corn. For 
example, if tFOO BAR) - (<A B C>) , (<P (F00 BAR) Q !#(F00 BAR) R>] = [<P <A D 
C> Q A B C R>J . A similar notation, "!#_", is used inside embedded formulas. 
If WHIZ BANG) - [<(A1 (B) tC]>J, (IP !#_(UHIZ BANG) Ql) = IIP ABCQ11. 

Segment forms make matching more complicated. Strictly speaking, these 
two formulas 

IP <!#?X !#?Y>] and [P <A B>] 

should match three ways 

IX ■» [<>], Y -> [<A B>]), 
IX -» [<A>], Y -► [<B>]), 
and (X -» [<A B>1, Y -» to] J . 

My matcher is too lazy. Occasionally this means deductive formulas have to be 
framed in terms of list operations instead of in the most concise style. 

Semantics 

While I am in sympathy with Hayes's (1974) contention that the semantics 
of a representation is very important, the subject seems much too complicated 
for practical representation schemes. NASL is a modal calculus, which should 
have an attractive model theory like Bressan' s (1972). However, operators 
like "/: CONSISTENTLY" ruin it. Furthermore, there is a pragmatic component to 
many predicates which could not be expressed model theoretically. For 
example, "/tCONSEQ" and V:ANTEC" both mean "OR," but they are used in 
different ways. Consequently, the most precise description of the meaning of 
the language is a description of STP (Appendix 4) to account for the strictly 
semantic "meaning" of a symbol; and the following index of pragmatic 
predicates with an informal description of the pragmatic meaning the system 
assigns to each one. 

Here is a list of built-in, pragmatic predicates, with an informal 
description of each. 
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Predicates and Functions with Meanings to the Interpreter 

Task Specification and Relation 

t/:TASK | name | < -input pvars- > 

(\ ( -vars- ) |action|) 
< -output pvars- >] 
means task name, which consists of doing action with the values of the 
input pvars substituted for the lambda-variables, is worth doing. It nil! 
produce output values to be bound to the output pvar3. 



[/:SUBTASK | task name 1| | task name 2|) 
ti nii/wnivin .1 ... \ 1-.1. n 




i 




t*m « » * , 



J^lIL^LZL WJHUOW It! PWSTJ u "„; «o d.rec, (he 

statu. SUCCS-ENABLEO. These assertions «» "-"" 
f low of control . 

[/..TASK -STATUS | task name | J 

[/:ENAB-STATUS | task name 1 

t/:TASK-ACT10N | task name| |actionlJ 

t/: REDUCED I task name 1 3 

i^de^i-on"^ state 0, a U* a, d.scussed in Sec,. ...B.I. 

nnlshed *«, a /.FINISH ta.K. (Sea belou.) 

Primi fives 

[/.HOD-HANIP Itasknamel |action| |deletelist| |addll-t|l 

I/xHoNITOR Ifirmulal (\ <M |act.on| )1 

[/:SET ' (expression! lvalue J . mmveg /jMOO-tlANIP defines thr 

These are the non-macro worldly prim m NJT0R create 9 a policy of 

delete M.t and addlist of the g've" t ^ ^ ^ th- given act-on 

looking for the erasure of fo ™ ul * * n ^? na t 9 d j d the erasing.) /:SET ..used 
f?ho variable v will be bound to the task that d a xne quantity 

T o he ch V ang: ab or e set the value of the expression; th, ^should ^^ ^ ^ 
like voltage or resistance, not a pvar. 
they were model manipulations. 



[/..INFER Mpropositionl < -task names- >1 
[/.FIND (\ t|v x l ... |v n D lexpDl IP 1 

[/: FIND-ALL | property]! ==> <|pvar > 



• IP^I* 
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are assigned to the pvars. If a choice of answers is required, this will be 
reflected in the data-dependency supporting these values. /:FIND-ALL takes a 
property of one argument, and returns a tuple of all the objects which satisfy 
it. /;EVAL calls the evaluator and returns the value. 

/:INFER is used to write special inference rules. The proposition given 
is recorded, supported by the propositions recorded by the specified task 
names. For example, the following task net doe3 the obvious 

t/:TASK MINOR <> (\ (/:FINO (\ (HAN SOCRATES)))) <>] 
t/:TASK MAJOR <> 

(\ (/:FIND (\ (IMPLIES (MAN ?X) (MORTAL ?K))))) <>] 
[/:TASK CONCLUSION <> 

(\ (/: INFER '(MORTAL SOCRATES) <MIN0R MAJ0R>)> '<>] 

t/: OUTPUT < -vals- >] «> < -hyars- > 

i/sfflm |i r |] 

Po leu who^ SUCCesSOrs **> ™ be enabled; *BEGUN means Ih , V a 

AOU P^ B . ke C [/^?M^,N n ?SHEm en b ab ^ ^ ^ P °' iCy ' 9 " F »^HLD. 
to be made pvar'vew'" &.!T t.2* UFOOH ' J" ^ V3 ' UeS * "«""- 

sets (Pv5n ! F °?k 'T 1 ^ ,X (V> (/!0UTPUT < ?V >> > <MPV2)>] 
sets t(PV2)] to the value of UPV11J when it becomes available. 

t/:CONTINUE | task name| |action|] 
t/rFINISH | task name| |action|] 

sublasks ITVIT ar >* USed t0 COntr0 ' P° ,ici es. When all the primary 
created as a sub 12 VE"' h f Ve been finished ' a /iF,NISH task »'■ ' I be 
reduce it Th* , ? P0 " Cy? '* ' 9 Up to the user to su PP'y rules to 

task! lac'tiJn I "! U 3 ' 30 eXeCUte actions of the f °™ ^CONTINUE Ipolicy- 

II?B.l.) ' P m mtermit ^ nt execution of the policy. (See Sect. 

Macro Pr imi t i ves 

[/: DO-SUBNET |plan schema | |vars mapl] 

/. ! MA?M NS ^ NC w, ,P,an in3tanCe| ,p,an 9Chema ' l3upertask|] 
l/:MAIN |subtask| |supertask|] 

standa^i!!H ned H in . ChaPte : "' theSe f ° rmU,as are used in attaching 
standardized subnetworks to the current plan. 

r f / : ™ |action 1,,(N ( " vars - > taction 2| )] 
K S n2^J aCtion U (X ( " vars - » < -actions- > )] 
r/nn .P. ,primar y actionl < -secondary actions- >] 
l/:UO-ALL < -actions- > |action|] 

a J 1 ? 6 !! J acr ° 8 e,ab °[ ate into various standard structures. /:SEQ turns into 
of the second I '^ V'V *' "^ fBedB PV3r3 t0 the secon * "™ outpu 
°t 5 I"! k the ° UtP ^ tS ° f the /!SEQ ' /:F0RK produces n ° P-ar values; 

other tasL TH » PeP ac ,0n ;. act i? n 1 being the predecessor of each of the 

/•WHILE starts aVtH" 63 ° f T"™ * " ° UtpUtS are fed to the accessor tasks. 
th« *Zu I L 6 secondar y actions as policy tasks with /:SCOPE equal to 

the task for the pr.mary action. /:D0-ALL carries out all the actions n no 
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particular order, outputting the values of action's pvars. 
Task Reduction 

[/: TO-DO | task name| | act ion 1| | output pvars | | act ion 2|J 
means, "action 2 is an effective, permitted, and feasible way of doing the 
task named which consists of action 1 and outputs the given pvars." Deducing 
formulas of .this kind is the first resort in reducing problematic taskc. 

[/: REPHRASE | task name| | act ion formula| | output pvars |] 
/.rnnn ^ i0 ?^ ^j 1 * must be reduced b « user-supplied rules, is set up uhen 

/Ireduced " Sect " "• C * 2, It9 object i9 to ,eave the ,ask 

Predicates with Meanings to the Choice Protocol 

[/:CH01CE |choice name| |context| |formula|] 

means a task or the executive (context) requires a choice regarding an-uiPrs 
to formula. The choices are recorded by formulas like 
t/:0PTJ0N (choice name| |option name| |answer|] 

[/: RULE-OUT |option|] 

[/:RULE-JN |option|] 

[/: RULE-TOGETHER < -options- > |new formula|] 

These three kinds of formulas are looked for repeatedly, In this order on 
eacn pass. So, for example, if a formula is /:RULED-0UT before the /: RULE-IN- 
rules are looked at, it has lost its chance. See Sect. I I.C.I. 

[/: QUIESCENCE | choice name|] 

is recorded when no activity occurred on a choice cycle. It is used to 
cause further forward deduction of /:RULE statements. 

Functions and Predicates Denned by BuiU-ln Axioms 

[ELT t x | | tuple)] means x is an element of the tuple. 

[SET-OF-ALL |prop|) denotes the set of all objects with the property 

prop. 
[MAPCAR |f | |tuple|] denotes the tuple obtained by applying f to 

every element of the tuple. 
[DEL |x| |tuple|] denotes the tuple obtained by deleting the first 

occurrence of x from tuple. 
ISUBTUP | tup 1| | tup 2|] means every element of tuple 1 i s an 

element of tuple 2. 
[CONTAINS | formula 1| | formula 2|] is true if formula 2 occurs 

somewhere inside formula 1 (as a proper 

subexpression). 
rc'Ic'SI? 1 . |formula l ] true of atomic-symbol formula like [[A]) 
rnc |formula|] true of formula of variable, like IPX]] 
[DEN |formula|] strips a layer of brackets off formula. (See abovn. ) 



[/: 



|x| |y|J true i f x and y match; else assumed false. 
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[" 1*1 |y|J true if x and y designate the same thing. To test 

this, the system first tries matching, 
then evaluating {via "-/>") x and y 
and trying the match again. 

[PRESUMABLY ' |proposi t i on | |use|l if true, may assume the 

proposition from inability to disprove it. 
(See Sect. II.B.2.) 

tXORl | pat | < -propositions- >] means exactly one of the proposition? 

is true if the pattern is. E.g., 
tXORl (LIVING ?X) 

< (ANIMAL ?X) (VEGETABLE ?X)>] 

[NFUN |n| |f|] denotes a function of n arguments which makes a list 

of them and applies f to it. E.g., 
[NFUN 3 (\ (L) (+ !#?L) )] 
= [\ (X Y Z) (+ ?X ?Y ?Z)J 

[+ -args-] t- |x| |y|] t* -args-1 [// |x| |y|] 

arithmetic functions. These are simplified by built-in LISP functions 
called by the evaluator. 

t/< |x| |y|l [/> |x| |y|] [-/< |x| |y|] [/>- |x| |y|] 
arithmetic inequalities 

Predicates with Meanings to the Theorem Prover 

Pragmatic versions of "OR": 

[/:C0NSEQ |p| |g|] 

[/:ANTEC \p\ \q\) 

[/:GEN \p\ |q|] 

The first two are used during backward chaining (a call to STP). The 
second is also used during forward chaining (a call to RECORD). /:GEN is 
really a call to STP in the midst of forward chaining. See Sect. II.B.2. 

[/:PKT |name| Ipacket vars| -conjuncts-] 

Like [AND -conjuncts-], but indexed differently, and more efficiently if 
most of the conjuncts will never be referenced. 

[=/> '|left| |right| ] 

means [= |left| |right|], but it also means that any expression subsumed hy 
left should be replaced by right wherever it appears (except inside a quoted 
expression). In practice, this replacement 19 done mainly in newly detached 
deductive conclusions. 

[^CONSISTENTLY ' Iproposi t ion|] 

is true iff the proposition cannot be refuted by STP in the current data 
base. If the proposition has free variables, they will be converted to Skolem 
forms before trying the refutation. 
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[/:DD |supporter| |path| < -supporters- > |supportee|] 

t/:SUPPORT < -supporters- > |supportee|] 

are used to access data dependencies as though they were stored in the data 
base. The /:D0 formula is true if there is a data dependency linking the 
supporters to the supportee. These are tuple-fied versions of the labeled 
treelets described in Sect. II. D. In particular, the element supporter must 
appear in the supporters treelet, with labels in path, For example, ue miqht 
have 

t/:DO t/:TASK T0687 <> tt () (PUTON A B)) <>] 
<DO-ACT-RESULT> 
< (DO-ACT-RESULT <[/:TASK T0G87 <> (X () (PUTON A B)) <>1 > 

<D0-APRIN <M0VE-DEFN»)> 
[ON A 811 

/:SUPPORT is simplified version in which the supporters must be just a list of 
deductive supporters. It is equivalent to [FORALL (S) (IMPLIES (ELT ?S < - 
supporters- >) (/:DD ?S <> < -supporters- > |supportee| ) )] . 

tT (reference point| |term|] 

IS * |proposi t ion|] 

These are the built-in modalities. The first is the value of term from the 
given reference point; the term is usually a fact with value true or raise. 
IS ' | fact |] means "S begins to be true"; it amounts to a special treatment of 
the data dependency that supports it. 

[FRAME |ref point | < -ref points- >] 

[N |ref point| ' | fact |] 

Computationally efficient ways of using modalities. Uhen the system tries 
a deduction of a T-formula, it will try to smash the reference point to a data' 
pool using these formulas. See Sect. II. B. 2. 

Predicates with Meanings to the Matcher 

Formula Meaning 

[/?/? |sym|] Inside an embedded formula, matches a variable with 
the symbol sym. 

Example: [[\ (_?+V) (F (/?/? _?+V))]] 
matches [ [\ (X) (F ?X)]] with +V - [[X]]. 

tIDN |n| |k|] The identity function of n args that returns arg k. 
Matches [\ (^...X,.) ?X| k ,] 

[K |n| |c|] The constant function of n args with value c. 
Matches [\ (^...X-J |c|] 
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[CMP | fun | < -funs- >] 

The composition of fun with the funs. If there are 
n of them, each with m args, this matches 

t\ <K X - - - X | m | > C(fun| -args-)], 
where the i th "arg" is of the form 
[|fun;| ?Xj ...?X, m ,l. 

Examples: tCMP SIN <?F>] matches [SIN] with F -» [IDN 1 1] . 
[CMP F00 <?F1 ?F2>] 

matches t\ (X Y) (F00 (+ ?X ?Y) (- ?Y ?X))] 
with Fl -» t+] and F2 - t\ (X Y) (- ?Y ?X)] 



Appendix 2 -- A Listing or DESI 

This is the current (June 27, 1977) version of the design knowledge. It 
is complete except for the definition of LISP functions defining macro-actions 
like CONFIG. (See Chapter III.) 

In Appendices 2 and 3, NASL formulas are defined and added to the data 
base with the function DEFULA, which is somewhat similar to MACLISP'S DEFUN. 
The expression 

tOEFMLA | name | |formula| |dest mat ion|] 

names the formula and adds it to the data pool that \s the value of 
destination. The destination is optional; If it is absent, the current pool 
CURRENT-DP* will be taken. 



(DEFflLR STflSK-OEFN t-/> fl (STRSK nSK ?SUPER ?! ?fl ?0> 

(AND </:TRSK ?TSK ?I ?fl ?0) 

(/sSUBTASK ?TSK ?SUPER)>1 

GENERRL-DP*) 

(DEFflLA DEVICE-CLASSES 

[X0R1 (IS DEVICE-TYPE '0) 
<(BflSIC-DEV-TYPE ?D) 
(SUPEROROINflTE-OEV-TYPE ?D>>]> 



(DEFHLR BflSIC-DEFN [EQUIV (BRSIC-OEV-TYPE ?X) 

(NOT (EXISTS (Y) (SUB-DEV-TYPE ?Y ?X) >>)) 



(OEFflLfl MAIN-OEV-TYPE {-/> fl (ttAIN-DEV-TYPE 'X 'DT> (DEV-TYPE 'X ?0T>]> 

(DEFOLH SUB-DEV-TYPE-1 t-/> fl (SUB-DEV-TYPE ?DT1 ?DT2) 

(-/> fl (DEV-TYPE ?X ?DT1) 

(DEV-TYPE ?X ?DT2))1) 
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(DEFHLA BASIC-DEVICE-ClflSSES 

IX0R1 (BASIC-DEV-TYPE '0) 

<(PRI(1ITIVE-DEV-TYPE 'D) 
(C0I1P0SITE-DEV-TYPE '0) 
(IDEAL-DEV-TYPE ?0)>) 
GENERAL -DP») 



(DEFI1LA COMPOSITE-OEVICE-CLASSES 

IX0R1 (COflPOSITE-OEV-TYPE >D) 
<(GENERAL-DEV-TYPE >D) 
(SPECIALIZED-OEV-TYPE ?D)>] 
GENERAL -OP*) 



(OEFHLA GENERAL -DEFN [EOUIV (GENERAL-DEV-TYPE ?X> 

(NOT (EXISTS <Y) (DERIVED ?X ?Y) ))]) 



(DEFMLA SPEC-OEV-TYPE-1 

t-/> A (SPEC-DEV-TYPE ?OTi ?0T2) 

(-/> A (OEV-TYPE 'X ?0T1> (OEV-TYPE ?X ?DT2))J) 

(OEFHLA SPEC-OEV-TYPE-2 

t-/> A (DERIVED ?DT1 '0T2> 

(-/> A (SPEC-OEV-TYPE '0T2 ?DT3) 

(SPEC-OEV-TYPE ?0T1 ?0T3>>]> 



(DEFI1LA SPEC-OEV-TYPE -3 

t-/> A (SPEC-OEV-TYPE ?0T1 ?0T2) (SPECIALIZED-DEV-TYPE ?DT1)I 
GENERAL-DP*) 



(OEFHLA SOUL-ON-ICE 

t-/> A (DERIVED >DT ?G) 

(-/> A (riAIN-DEV-TYPE 'X ?0T) 

(AND (HAIN-OEV-TYPE (SOUL ?X) ?G) 

(-/> C (/:SUBTASK ?T (DEEP-FREEZE (SOUL ?X>>> 
(/sSUBTASK ?T (DEEP-FREEZE ?X)))))J) 

(OEFHLA EASY-DESIGN 

t/:TO-DO 7TS1C (DESIGN (\ (X) (OEV-TYPE ?X ?0T) )) <?NRHE> 
(HAKE ?OT)I) 



(OEFHLA +DESI-1 

1/iTO-DO ?T (/:REPHRASE ?TStC [DESIGN _?+PI <?DEVNAnE>) 
<> 
(/iDO-SUBNET (OESI-REPHRASE-PLRN ?*P ?TSK ?DEVNBfIE> <>)) 
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CENERflL-DP*) 



(OEFOLfl +DESI-2 

t-/> A (/: PLAN-INSTANCE ?P1 

(DESI-REPHRflSE-PLHN ?+P 7TSK ?DEVNRHE> 
?SUP> 
(-/> H (/: = ?+P t\ (_?+V) _?+BJ> 
(AND 

t/:TRSK (EXPLODER ?PI) <> 

<\ () (O-EXPLOOE ?+P>) <>) 
</:SUBTRSK (EXPLOOER ?PI) ?SUP) 

</:TRSK (ACCOUNT-FOR-ALL ?PH <> 

(S (RCCOUNT-FOR-ALL-SHRRDS ?+P> ) <>) 
(/:SCOPE (RCCOUNT-FOR-ALL ?PI) (EXPLOOER ?PD) 
(/SUCCESSOR (RCCOUNT-FOR-RLL ?PI> (EXPLOOER ?PI)> 

(/sTASK (CORE-FINDER ?PI) .<> 

(\ () (/:FIND (\ (+OT) 

(CORE-DEV-TYPE ?+P ?+DT))>> 

<'(CORE-OT >PI)>> 
</:SUBTRSK (CORE-FINDER ?PI> ?SUP) 

(STRSK (HRIN-TRSK-INFERER ?PI> ?SUP <' (CORE-OT ?PI)> 
(\ (+OT) (/! INFER 

• (RND (STRSK (HfiKER ?TSK) ?TSK <> 

(\ (HRKE (OEN ?+DT>) ) 
<• (WINNER ?TSK)>) 
(/sHRIN (HRKER ?TSK> ?TSK)> 
< (CORE -FINDER ?PI)>) > 
<>) 

(^SUCCESSOR (HRIN-TRSK-INFERER ?PI> 
(SIDE-TRSKS-FINOER ?PI>> 

(STASK (SIOE-TRSKS-FINDER ?PI) ?SUP <> 
(\ () (/: INFER 

MFORRLL (+ST) 

(-/> G (SIDE-TASK ?+P ?+ST> 
(EXISTS (T) 

(RNO (STRSK ?T ?TSK 

<• (WINNER ?TSK)> 
(DEN ?+ST) 
<>> 
(/SUCCESSOR 
(HRKER ?TSK) 
?T)) )) ) 
<>) ) 



(STRSK (FERTURES-FINOER ?PI) ?SUP <> 
(\ () 
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(/s INFER 

MFORALL <*FT> 

(-/> C (0-FEATURE ?*P ?+FT> 
(EXISTS (T) 

(RNO (STASK ?T ?TSK <> 
(\ O 

(D-NOTE (OEM ?+FT>> ) 
<>> 
(/! SCOPE ?T MAKER ?TSK>> 
(/: SUCCESSOR 

?T (IWKER ?TSK>>) >) > 
<>) ) 
<>) 

(STASK (GATHERER ?PI) ?SUP <> 

(\ O (/! INFER • (/sREDUCEO ?TSK) 
< (CORE -FINDER ?PI> 
(SIDE-TASKS-FINOER ?PI) 
(FEATURES-FINOER ?PI>>) ) 
<>) 

(/! SUCCESSOR (EXPLOOER ?PI) (COBE-FINOER ?PD) 
(/sSUCCESSOR (EXPLOOER ?PI) 

(SIOE-TASKS-FINDER ?PI>) 
(/sSUCCESSOR (EXPLODER ?PI) (FEATURES-FINDER ?PI>) 
(/sSUCCESSOR (HfUN-TASK-INFERER ?PI) (GATHERER ?PI>> 
(/sSUCCESSOR (SIDE-TRSKS-FINDER ?PI) 

(GATHERER ?PI>> 
(/sSUCCESSOR (FEATURES-FINDER ?PI) (GATHERER ?PI>) 

(/sflAIN (GATHERER ?PI) ?SUP)))J 
GENERAL-DP*) 



(THE INTENT OF D-EXPLOOE IS TO DISCOVER O-SHRROS, UHICH GENERATE 
J (1) CORE-OEV-TYPE, THE KIND OF OEVICE WHICH HAS THE OESIREO PROPERTY 
I (2) D-FEATURES, UHICH URL GUIOE (AS POLICIES) THE tIRKER OF THE OEVICE 
I (3) SIDE-TASKS, UHICH TYPICALLY ARE CONSTRAINTS ON PROPERTIES OF THE 
» DEVICE 



(DEFflLA D-EXPLODE 

I/: TO-DO ?T (D-EXPLOOE ?+PR0P> <> 

(/s INFER ' (D-SHARO 7+PROP ?+PKOP> <>)J) 

(DEFHLA D-SHARO 

t-/> A (D-SHARO ?+P t\ (_?+V) (AND !f_?+CS)I) 
(FORHLL UP (/sGEN (NOT (ELT ?+C ?+CS>> 

(O-SHHRO ?+P l\ (_?+V) _?♦«)) )J 
GENERAL-DP») 



(OEFHLA ACCOUNT-FOR-ALL-DO 
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I/iTO-OO ?T (ACCOUNT-FOR-ALL-SHRROS ?+P) <> 

(/sPRId *SETUPH 
GENERAL -DP*) 

(DEFflLfl ACCOUNT-FOR-ALL-FIN1SH 

t-/> fl (/:TASK-RCTION ?FIN (/:FINISH (RCCOUNT-FOR-RLL ?PI))) 
(AND (/;REDUCEO ?FIN) 

<-/> G (RND (/! PL AN- INSTANCE ?PI 

(DES I -REPHRASE -PLAN ?*P ?+TSK 
?+OEVNAt1E 
?*URY> 
?SUP) 
(O-SHARO ?+P 7+SHRRO)) 
(STASK (SHARD-ACCOUNTANT 7+SHRRD) ?FIN 
<> 
(\ 

(ACCOUNT-FOR-SHARD 7+SHRRO 
7+P) ) 



(OEFtlLR SHARD-ACCOUNT-DO 

t/: TO-DO 7TSK (ACCOUNT-FOR-SHARD 7+SHARD 7+P) <> 
</:CRLL (SHHRD-ACCOUNT-CHEAT 7+SHARD ?+P))l 

GENERAL-DP*) 
;THIS IS HANDLEO BY A LISP FUNCTION (NOT SHOUN) 
(IN THE CURRENT IflPLEtlENTRTION 



(OEFULA 0-NOTE-00 

(/iTO-00 7TRSK (D-NOTE 'PROPERTY) <> (/sPRltt *SETUP))> 

(OEFULA O-NOTE -FINISH 

t/:TO-DO 7TASK (/:FINISH 7PTRSK (O-NOTE 7PROPERTY)) <> 
(/iPRIM *FINISHEO)I) 

(DEFtlLA CQ-FUNS-1 t/iflNTEC (NOT (DERIVED-CO ' (?F ?X>>) 

(CONTROL -ATTRIBUTE ?F))> 

(OEFtlLR CQ-FUNS-2 t/iANTEC (NOT (IIWEOIATE-CQ ' (?F ?X))) 

(CONTROL-ATTRIBUTE ?F)J) 

(OEFULA CQ-SHARD 

t/:ANTEC (NOT (O-SHARO >+P t\ (_?+V) (• _?+EXPl _?+EXP2>])) 
(ANO (POS-CQ-SHflRO ?+P 7+V 7+EXP1 ?+EXP2> 

(POS-CQ-SHRRO >+P 7+V ?+EXP2 7+EXP1)))) 

(OEFULA POS-CQ-SHARO 

t/tRNTEC (NOT (POS-CQ-SHRRO ?+P 7+V 7+EXP1 7+EXP2)) 

(/:GEN (NOT (RNO (NOT (CONTAINS 7+EXP2 C(|??| _?+V)]>> 
(»/> '(DEN t\ (_?+V) _?+EXPll) 
?F) 
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(CONTROL-ATTRIBUTE ?F) 
(./> '(DEN ?+F) ?F)>) 
(SIDE-TASK ?*P 
t\ (_?+V> 

(CONSTRAIN <'(_?+F (|??| _?+V>>> 
(\ <X) (. ?X _?+EXP2> )) J))J 



GENERAL -DP*) 



(DEFflLA CORE-DT-1 

t/iANTEC (NOT (O-SHARO ?+P I\ (_?*V) (OEV-TYPE </?/? _?+V> 

_?*DT)J>) 
(CORE-OEV-TYPE ?+P ?+0T)]> 



; CHOOSING CORE-OEV-TYPES 

(DEFHLA CORE-DT-CHOOSE 

C/:ANTEC (NOT (CHOICE ?C ANSWER ICORE -OEV-TYPE _?++P _?++0)>> 
<-/> G (ANO (/lOPTION ?C ?A1 

ICORE-DEV-TYPE _?**P _?++011 > 
(/! OPTION ?C ?A2 

ICORE -OEV-TYPE _?++P _?++D2J> 
(SUB-DEV-TYPE (OEN (OEN ?+*01>> 
(DEN (OEN ?++D2)))) 
(/:RULE-OUT ?A1))J) 
|PLUS OOtlAIN-OEPENDENT INFO IN ZORCH 



(DEFflLA HAKE-BASIC 

I-/> A (BRSIC-DEV-TYPE 7DEV-TYPE) 

(/tTO-00 7TSK (HAKE ?OEV-TYPE) <?NAHE> 

(/:DO-SUBNET (tIAKE-BRSIC-NET 70EV-TYPE) <OEVNAHE>))J) 



(DEFHLA HAKE-BASIC-PLAN 

!-/> A (/: PLAN-INSTANCE ?PI (HAKE -BASIC -NET ?DEV-TYPE) ?SUP) 
(ANO (/:TASK (GRABBER 'PI) <> 
(\ () 
</:CALL 

(GRRBBA (\ (X) 

(HAIN-DEV-TYPE 7X 

7DEV-TYPE) ))) ) 
<*(DEVNfiHE ?PI)>) 
(/:HAIN (GRABBER ?PI) ?SUP))J 
GENERAL -DP*) 

(DEFHLA HHKE-PRin 

[-/> A (PRIHITIVE -OEV-TYPE 70EV-TYPE) 
(-/> A (/: PLAN-INSTANCE 

7PI (HAKE-BRSIC-NET 70EV-TYPE) ?SUP) 
(FORALL (Q C) 
(-/> G 

(FORALL (X) 
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(IMPLIES (OEV-TYPE ?X ?OEV-TYPE) 

(CONTROL ?Q ?X ?0 ?C>> ) 
(EXISTS (SUB) 

(STRSK ?SUB ?SUP <' (DEVNRI1E ?PI)> 
(\ (X) (SELECT-VALUE 

M?Q ?X>> ) 
<>) )) ))]) 



(DEFflLA nfltCE-COOPOSITE 

C-/> A (COI1POSITE-OEV-TYPE ?OEV-TYPE) 
(-/> A (/: PLAN- INSTANCE 

?PI (HAKE-BAS1C-NET ?OEV-TYPE) ?SUP) 
(EXISTS (SUB) 

(STRSK 'SUB 'SUP <'(DEVNAI1E ?PI>> 
(\ (X) (EXPAND ?X> ) 
<>) ))]) 



(OEFM.R HAKE -IDEAL 

l-/> A (IDEAL-DEV-TYPE 7DEV-TYPE) 
(-/> A </:PLRN-INSTflNCE 

?PI (tlRKE-BASIC-NET 7DEV-TYPE) ?SUP) 
(EXISTS (SUB) 

(STASK ?SUB 'SUP <' (DEVNAHE ?PI)> 
(\ (X) (IMPLEMENT ?X) ) 
<>) ))I) 



(DEFMLA COMPONENTS-NOTICE 

{-/> A (COHPONENTS ?X 'PARTS) 

(-/> C (ELT 7PART 7PARTS) 

(-/> A (MAIN-DEV-TYPE ?X ?DT) 
(EXISTS (PI) 

(AND (/sPLAN-INSTANCE ?PI 

(HAKE-BRSIC-NET ?OT) 
(OEEP-FREEZE ?X>) 
(/sFINISHEO (GRABBER ?P1>>> >>>) 
GENERRL-OP*) 

jOEFINITION OF EXPAND 

t THE MOST GENERAL SPECIALIZATION RNO ANY DEFAULT SPECIALIZATIONS OF fl 
I DEVICE TYPE ?G ARE TREATED THE SAME HERE, BUT (A) THE CHOICE RULES 
I BELOU UILL TAKE THE DEFAULT, OR (B) USER-SUPPLIED RULES UILL 
, FAVOR THE GENERAL. 

(DEFI1LA MOST-GENERRL-DEFN 

l-/> A (tlOST-GENERAL-SPEC 'G 'OT) 
(AND (SPEC-DEV-TYPE 'OT ?G> 

(-/> C (MRIN-OEV-TYPE ?X ?G) 
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(/: TO-00 ?TASK (EXPANO ?X> <> 
(SPECIALIZE ?X ?OT) )J)1) 



(DEFflLA DEFAULT-SPEC-OEFN 

C-/> A (OEFAULT-SPEC ?G ?OT) 

(-/> C (MAIN-DEV-TYPE ?X ?C) 

(/: TO-DO ?TflSK (EXPANO ?X) <> 
(SPECIALIZE ?X ?0T) ))]) 



(DEFMLA SPECIALIZE-DEFN 

[-/> C (HAIN-DEV-TYPE ?DEV ?OLO-DEV-TYPE) 

(/:HOO-t1ANIP (SPECIALIZE ?OEV ?DEV-TYPE> 

<* (HBIN-DEV-TYPE ?OEV ?OLD-DEV-TYPE>> 
<* (HAIN-DEV-TYPE ?DEV ?DEV-TYPE)>)J) 

J IF ONE OEVICE-TYPE IS A SPECIALIZED VERSION OF ANOTHER, TRY 
j TO TAKE THE IIORE SPECIFIC, OTHER THINGS EQUAL. 

(OEFHLA SPEC-DEV-BETTER 

t-/> A (DERIVED ?DT1 ?DT2) 

(-/> C (AND (=/> ' (DEN ?+DTl> ?DT1) 
(»/> '(DEN ?+0T2> ?0T2)) 
(-/> A (/.-OPTION ?C ?A1 

(/: TO-DO _?*TSK (EXPAND _?+DEV> <> 
(SPECIALIZE _?+OEV _?40Ti)J) 
(-/> A (/:QUIESCENCE ?C> 

(-/> G (/sOPTION ?C ?A2 

U J TO-00 _?+TSK 

(EXPANO _?+OEV) 
<> 
(SPECIALIZE 

_?+DT _?*OT2»> 
(/(RULE-IN ?A1)))))1 
GENERAL -DP*) 



(DEFMLA TUO-SPEC-DEVS-WORSE-THAN-ONE 
C-/> A (DERIVED ?OTl ?OT8) 
(-/> A (DERIVEO ?OT2 >OTO) 

(-/> G (AND (NOT (/:= ?0T1 >0T2>) 

(=/> ' (DEN ?+0T8) ?DT8) 
(=/> ' (DEN ?+0Tl) ?DT1) 
(=/> '(DEN ?+DT2) ?DT2)> 
(-/> A (/sOPTION >C ?A1 

I/: TO-DO _?+TSK (EXPANO _?+DEV) 
<> 
(SPECIALIZE _>+DEV _?+0TI)J) 
(-/> A (/:QUIESCENCE ?C) 

(-/> G (AND (/tOPTION ?C ?A2 

{/: TO-00 _?+TSK <EXPANO _?+DEV> 
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<> 






(SPECIALIZE _?+OEV _ 


?+DT2)J) 




</:OPTI0N ?C ?R8 








[/: TO-DO _?+TSK 


(EXPRND 
<> 


_?+DEV) 




(SPECIALIZE 


_?+DEV 


_?+DT8)D) 


(UNO 


(/:RULE-OUT ?R1) 








(/sRULE-OUT ?A2>>>>)>>)) 





(RUXILIRRY SUBTRSKS OF EXPRNO 
(DEFtlLR EXPAND-LOOKRHERD 

[-/> fl (/:TRSK-ACTION ?TSK (EXPAND ?DEV)) 
(TO-BE-EXPRNOED ?DEV ?TSK)I> 



(DEFflLA EXPRNSION-OBLS-00 

I/sANTEC (NOT (EXPRNSION-OBL ?OEV ?B)> 

(/:ANTEC (NOT (TO-BE-EXPRNOED ?DEV ?TN>> 

(/iTRSK (OBL ?OEV ?B> <> (\ ?B) <>))J) 



(DEFOLA GENERIC-CRS 

!-/> A (CENERIC-CR ?CA) 

(AND (CONTROL-RTTRIBUTE ?CA) 
(-/> A (/:POLICY 'TASK 

(CONSTRAIN <!#?QS1 ' <?CA ?DEV) !J?QS2> 
?P>1 
(-/> C (ELT ' (?CA ?X) 

<!#?QS1 M?CA ?DEV> !f?QS2>) 
(-/> R (TO-BE-EXPANDEO ?OEV ?TSK) 

(STASK (CA-CALC ?CA ?DEV) ?TSK 
<> 
(\ () 

(CALCULATE 

•(?CA ?DEV)> ) 
<>>))>» 
GENERAL -OP»> 

(OEFflLR flCQUIRE-DO-1 

[-/> C (ANO (REUSABLE 7DEV-TYPE) (DEV-TYPE ?X ?OEV-TYPE>) 
(/tTO-00 >TSK (ACQUIRE 70EV-TYPE) <?NAHE> 
(/sOUTPUT <?X>)))) 



(DEFHLR ACQUIRE-DO-2 

I/: TO-DO ?TSK (ACQUIRE 'OEV-TYPE) <?NAHE> 
(HAKE 'OEV-TYPE))) 



(DEFHLR REUSRBLE-1 (PRESUHRBLY '(NOT (REUSABLE ?X)) CI) 
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(DEFflLA REUSE-CETERIS-PARIBUS 

t-/> A (/i CHOICE ?C EXEC I/i TO-DO _?*TASK (ACQUIRE _?+OT) <_?+N> 

_?+MAYl ) 
(-/> A (/(QUIESCENCE ?C> 

(-/> fl (/s OPTION ?C ?IU 

I/tTO-00 _?*TASK (ACQUIRE _?*OT) <_?+«> 
(HAKE _?+OT)J) 
(/:RULE-OUT ?A1>))]> 



;IF SIOPLE EQUATION, TRY SOLVING IT 
(OEFnLA CONSTRAIN-DO-1 

[-/> C (t« <?UNK> 

(/iTHFINO 
(\ (U) 

(ANO (ELT ?U 'QUANTS) 
(/sCONSISTENTLY 
'(FORALL (VAL) 

(NOT (./> ?U >VAL>> ))) ))) 
(/iTO-DO ?TASK (CONSTRAIN 'QUANTS (CUP - <?F1 ?F2>>) <> 
(/iSEQ (CONSTRAINT-RESOLVE ?UNK ?F1 ?F2 ?QUANTS> 
(\ (VAL) 
(PROTECT 

'(SATISFIES 

?UNK (CUP - <?F1 ?F2>> 7QUANTSM 



jELSE, JUST ESTABLISH POLICY 
(OEFflLA CONSTRAIN-DO-2 

t-/> C (OR (NOT (:. ?F =)) 
(FOR ALL (UNK) 

(NOT (i. <?UNK> 

(/iTHFINO 
(\ (U) 

(AND (ELT ?U ?QUANTS) 
(/tCONSISTENTLY 
MFORALL (VAL) 

(NOT (./> ?U ?VAD) 
))) )))) )) 
(/! TO-DO ?TASK (CONSTRAIN ?QUANTS (CflP ?F ?P1>> <> 
C/tPRin *SETUP))I) 



jOEFINITION OF "CONSTRAINT" — 
(DEFHLA CONSTRAINT-1 

!-/» A (CONSTRAINT 70S ?P> 

(EXISTS (T) (/:POLICY ?T (CONSTRAIN ?QS ?P>> )]) 

(DEFflLA CONSTRAINT-2 

l-/> C (EXISTS (T> (/rPOLICY ?T (CONSTRAIN ?QS ?P>> ) 
(CONSTRAINT ?QS ?P)I) 
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(DEFHLA CONSTRA INT-RESOLVE -REPH 
C/i TO-DO 7RTSK 

(/: REPHRASE 7TASK 

tCONSTRA INT-RESOLVE _>+UNK 

(\ (_?+VARS> _?+EXPl» 
<\ (_?+VARS> _?+EXP2> 
<!#_>QUANTS>1 
<?VflLUE>) 
(/:SEQ (EQN-SOLVE 7+UNK (LAMBOA-APPLY (\ (_?+VfiRS> _?+EXPl) 

7+QUANTS) 
(LAHBDA-APPLY (\ (_?+VARS) _?+EXP2) 
?4QUflNTS)) 
(\ (+ANS) 

(/: INFER ' (AND (STASK (SETTER 7TASK) 7TASK <> 
(\ () (/iSET (DEN 7+UNK) 

(DEN 7+ANS)) ) 
<>) 
(/iHAIN (SETTER ?TASIC> 7TflSK) 
(/: REDUCED ?TASK>> 
<>) ))]> 



(DEFttLR EQN-SOLVE-DO-1 

[-/> C (RNO (ONE-OCCURRENCE 7+LFT 7+UNK) 
(NOT (CONTAINS 7+RGT 7+UNK))) 
(/: TO-DO 7TASK (EQN-SOLVE 7+UNKF ?+LFT 7+RGT) <7RNSV> 
(ISOLATE 7+UNK 7+LFT 7+RGT))]) 



(OEFHLA EQN-SOLVE-DO-2 

[-/> C (AND (ONE -OCCURRENCE 7+RGT 7+UNK) 
(NOT (CONTAINS '+LFT 7+UNK) >> 
(/! TO-DO 'TASK (EQN-SOLVE 7+UNKF 7+LFT 7+RGT) 
(ISOLRTE 7+UNK >+RGT 7+LFT))] > 



c?ANSV> 



(OEFULA EQN-SOLVE -DO-3 

l-/> C (NOT (ONE-OCCURRENCE C.7+LFT _?+RGTJ 7+UNK)) 

(/: TO-DO nSK (EQN-SOLVE 7+UNK 7+LFT 7+RGT) <7ANS> ■ 
(/sCALL (EQN-CHEAT 7+UNK 7+LFT ?+RGT)))J> 

;THE TERH "ISOLATE" IS FROJ1 BUNOY'S MNI-THEORY OF EQUATION SOLVING. 
» HIS NOTION OF "COLLECTION" IS ALSO APPROPRIATE, BUT NOT MPLEHENTED. 



(DEFflLR ISOLATE-DO-1 

t/:CONSEQ (/: TO-DO 7TASK (ISOLATE 7+UNKF 7+LFT 7+REL 7+RGT) 
<7RV ?ANSV> 

(OUTPUT < 7+REL ?+RGT>>> 
(NOT U 7+LFT 7+UNKF))]) 



(OEFflLA 1S0LATE-D0-2 
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t/tCONSEQ (/sTO-DO 'TASK (ISOLATE 7+UNKF 7+LFT 7+REL 7+RGT) 
<?RV ?RNSV> 

(/:SEQ (ISOLRTE-ONE-STEP 7+UNKF 7+LFT 7+REL 7+RGT) 
(\ UNEU-LFT +NEU-RGT) 
(I SOLUTE 7+UNKF ?+NEU-LFT 

7+REL 7+NEU-RGT) ))) 
(. 7+LFT 7+UNKF) ]> 

(OEFHLO ISOLRTE-ONE-DO-+ 

t/iCONSEQ (/sTO-00 HASK 

(ISOLRTE-ONE-STEP 7+UNKF 1+ ! *_?+ROOENDSI 

7+REL 7+RGT) 
<?LV ?RV> 
(OUTPUT <?+TER(1 t- _?+RGT (♦ !#_7+TERI1S>)>)> 
(NOT (AND (ELT 7+TERH 7+ROOENDS) 
(CONTAINS 7+TERH 7+UNKF) 
(« 7+TERMS (DEL 7+TERH 7+RDOENDS))))]) 



(OEFflLA SELECT-VRLUE-DO 

[-/> C (/tCONSISTENTLY 

MFORALL (VRL) (NOT U/> 7QURNT ?VRL>> )) 
(/! TO-DO ?T (SELECT-VALUE 70URNT) <> 

(/sCALL (CHERT 7QURNT (CQ-CLOSURE ?QURNT))))I) 
iSELECT-VRLUE IS HRNOLEO BY R LISP FUNCTION 
j IN THE CURRENT IHPLEMENTATION 



(DEFULA CQ-CLO-1 

!»/> * (CQ-CLOSURE 7Q) 

(/:THFINO (\ <C> (CQ-CLOSURE-ELT ?C ?Q) ))J) 

(OEFflLR CQ-CLO-2 

t-/> C (CONSTRAINT <!#?QT1 ?Q !#?QT2> 7P) 

(CQ-CLOSURE-ELT (CONSTRAINT <!#?QT1 ?Q 7QT2> ?P) 
>Q)J> 

(OEFtlLfl CQ-CLO-3 

t-/> C (AND (EQ-CLOSURE-ELT (CONSTRAINT 7QS ?P) ?Q) 
(ELT >Q1 70S) 
(EQ-CLOSURE-ELT ?C ?Q1)> 
(CQ-CLOSURE-ELT ?C 70)1) 

(DEFflLR SELECT-POSTPONE 

l-/> A (/:TASK ?TSK 'I (CMP DESIGN <?PF>) <?DEV>) 

(-/> A (/:TASK ?S 'I (CAP SELECT-VALUE <?QF>) <>) 
(AND (STASK (SELECT-Efl-ALL 7TSK) 7TSK <> 
(\ () (DO-ALL-SELECT-VALUES 7TSK) 
<>) 
(/:SUBTASK ?S (SELECT-Efl-ALL 7TSK>> 
(/:REOUCEO (SELECT-Efl-ALL ?TSK>) 
(-/> A (TOPO-CHANGE-ACTION-FUN ?F> 
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<-/> A (/:TRSK ?T ?IHS ■ 

(CUP ?F 7FS> 70UTS) 
(/SUCCESSOR 
?T (SELECT-EH-ALL ?TSK))))))J 



CENERflL-DP») 



(DEFHLA MAKE-CHANGES-TOPOLOGY 

(TOPO-CHANGE-ACTION-FUN MAKE1) 

(DEFHLA FIX-CHANGES-TOPOLOGY 

ITOPO-CHANGE-ACTION-FUN FIX!) 

(DEFMLA QVAL-PROTECT 

t-/> C (AMD (=/> ?Q ?VRL) 

(»/> MOEN 7+FACT) (./> ?Q ?VAL))> 
</:TO-DO 7TASK (PROTECT '(SATISFIES ?0 ?C ?QOANTS)) <> 
(/: MONITOR 7+FACT 
(\ (T) 

(/sCONTINUE 7TASK 
(PROTECT 

'(SATISFIES ?Q ?C ?OUAMTS))) )))!) 



(DEFMLA PROTECT-COMTINUE 

t/»TO-00 7TASK (/sCONTINUE 7PTASK 

(PROTECT '(SATISFIES ?Q 7C 7QUANTS))) 
<> 
</:DO-SUBNET 

(PROTECT-COMTINUE -NET 7PTASK ?Q ?C 7QUANTS) <>)J) 



(DEFMLA PROTECT-CONTINUE-PLAN 

(-/> A (/:PLAN-INSTANCE 'PI 

(PROTECT-CONTINUE-NET 7PTASK ?Q ?C 70UANTS) 
7SUP) 
(AND (STASK (RECHECt-ER ?PI> ?SUP <> 

(\ () (VERIFY '(SATISFIES ?Q ?C 70.UANTS)) ) <>) 
(STASK (VALUE-FINDER 7PI) 7SUP <> 
(\ () 
(/:FINO 

(\ UNEUftON) 

(EXISTS (NEUVAL) 

(ANO (./> ?Q 7NEUVAL) 

<«/> '(DEN 7+NEHMON) 

U/> 70 ?NEMVAL)>> ))> ) 
<• (NEUflON ?PI)>> 
(STASK (REflONITOR 7PI) 7SUP <• (NEUMON ?PI)> 
(\ (+FACT) 

(/i MONITOR 7+FACT 
(\ (T) 

</: CONTINUE 7PTASK 
(PROTECT 
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'(SATISFIES ?Q 7C 

7QUANTSM) )) )))J) 

(DEFflLA VERIFY-00 

t/i TO-DO ?TSK (VERIFY ' ?P> <> 
(/sFINO (\ () ?P> ))) 

(OEFHlfl SPEC-SCHEMA-DEFN 

[-/> H (SPEC-SCHEMA 'SCHi >SCH2) 

(-/> A (/:PLAN-INSTANCE ?PI 7SCH1 >SUP> 

(/: PLAN-INSTANCE ?PI ?SCH2 ?SOP))J) 

I THIS PREDICATE IS USEFUL IN RELATING A SCHEMA TO ITS SPECIALIZERS 
(OEFHLA REOUCE-DEFN 

l-/> A (REDUCE 7THSKS 7TASK) 

(AND (-/> G (ELT ?T 7TASKS) (/tSUBTASK ?T 7TASK)) 
(/:REDUCED 7TASK)))) 



I THIS IS A USEFUL PREOICATE ON FROZEN TASKS 
(OEFHLA FUNCTION-OEFN 

{-/> A (FUNCTION ?OEV ?TSK) 

(-/> A (tIAIN-DEV-TYPE ?OEV 7DT) 
(EXISTS (ACQ) 

(AND (/:TASK ?ACQ 71 ?A <?OEV>) 

(/: TASK-ACTION 7ACQ (ACQUIRE 7DT>) 

(/:REOUCEO ?ACQ) 

(REDUCE <?ACQ> ?TSK>> >))> 

I IF ONE PLAN-SCHEtIA IS A SPECIALIZED VERSION OF ANOTHER, TRY 
t TO TAKE THE MORE SPECIFIC. (THIS IS REALLY MORE GENERAL THAN 
; THE UORLO OF DESIGN.) 

(DEFMLA SPEC-IS-BETTER 

[-/> A (SPEC-SCHEMA ?SCH1 ?SCH2) 

(-/> G (AND U/> ' (DEN 7+SCH1) 7SCH1) 
(./> MDEN 7+SCH2) ?SCH2)) 
(-/> A (/: OPTION ?C ?A1 

I/i TO-DO _?+TSK _?+ACT _?+OUTS 

(/:DO-SUBNET _?+SCHl _7+VARSl)I) 
(-/> A (/i OPTION ?C ?A2 

I/sTO-00 .,7+TSK _?+ACT _?*OUTS 
(/iDO-SUBNET _?*SCH2 

_?+VARS2)J) 
(/iRULE-IN ?A1))))I) 



(OEFHLA TUO-SPECS-WORSE-THAN-ONE 

t-/> A (SPEC-SCHEMA 7SCH1 7SCHB) 

(-/> A (SPEC-SCHEMA ?SCH2 7SCH8) 

(-/> G (ANO (NOT (/i. 7SCH1 7SCH2)) 
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(./> '(DEN ?+SCH8) ?SCH8) 
(./> MOEN ?+SCHl> ?SCH1) 
(-/> '(DEN ?»SCH2> ?SCH2>> 
(-/> A 

(/! OPTION ?C ?fll 

C/s TO-DO _?+TSK _?+ACT _?+OUTS 

</i DO-SUBNET _?+SCHl _?+VARSl>)> 
(-/> G (RNO (/: OPTION ?C ?B2 

t/i TO-DO _?+TSK _?*ACT 
_?*OUTS 
(/lOO-SUBNET _>SCH2 
_?+VHRS2)J> 
(/lOPTION ?C ?R8 
I/! TO-DO _?+TSK _>+ACT 
_?+OUTS 
(/t DO-SUBNET _?+SCH8 
_?+VARS8>J)) 
(flNO (/: RULE-OUT ?A1) 

(/.•RULE-OUT ?A2))))))l) 



Appendix 3 -- ft Listing of ZORCH 

Thi9 is the current version of DESI's electronics knowledge. Much of it 
interacts with the more general rules of the previous appendix. 



(INTSECT-OISPARITY* :. 1808) 

(ALLOC '(LIST (180888. 158808. 8.6)>> 

(PHYSICAL KNOULEDGE 

{EVERY NODE IS A TERtllNAL 

(OEFflLA NODE-TRMN 

IFORALL (X) (-/> A (DEV-TYPE ?X NOOE) (DEV-TYPE ?X TERMNAL)))) 

jKCL FOR DEVICES 

(Oefula kcl-1 

!-/> A (TERniNAL-NAnES ?X ?TRHIN-TUP) 

(CONSTRAINT (HAPCHR (LAtlBOA (T) » (I (?T ?X)> ) 
?TRniN-TUP> 
(NFUN (LENGTH HRMN-TUP) 

(LAHBOA (L) (. (♦ !#?L) 8>>)>l> 

;KCL FOR NODES 
(OEFflLA KCL-2 

l-/> A (>/> ' (NODE-TERniNftLS 7N00E) ?TRHIN-TUP) 
(CONSTRAINT <* (I 7N00E) 

!#(riHPCAR (\ <T) *(I ?T> ) 
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?TRHIN-TUP>> 
(NFUN <♦ (LENGTH ?TRMIN-TUP> 1) 

(lambda (D (. (♦ !#?d e))))i) 

; ...AND COMPOSITE OEVICES 
(DEFMLA KCL-3 

t-/> R (COMPOS I TE-DEV-TYPE 'DT> 

(-/> A (OEV-TERMINALS ?DEV ?TRHIN-TUP> 

(CONSTRAINT (HAPCAR (\ (T> '(I ?T) ) 
7TRHIN-TUP) 
(NFUN (LENGTH ?TR«N-TUP> 

(LflflBOR (L) (. (+ !#?L> 8) 
>)))J) 



jKVL FOR NOOES 
(DEFMLA KVL-1 

[-/> R (*/> • (NODE-TERMINALS 'NODE) 7TRMIN-TUP) 
(-/> G (ELT ?TRMIN nRHIN-TUP) 

(CONSTRAINT <' (V ?TRHIN> '(V ?NOOE)> •>>)> 



;SOME TERfllNALS HAVE NODES THAT THEY ARE TERMINALS OF 

(OEFtlLA NODE-OF-1 {-/> A (=/> ' (NODE-TERMINALS ?N) ?TS) 

<-/> G (ELT ?T ?TS) (NOOE-OF ?T ?N))J) 

(DEFMLA NOOE-OF-2 (PRESUMABLY '(NOT (NOOE-OF ?T ?N)) CD 



I NOOES CAN BE MERGED 
(DEFMLA NOOES-MERGE-MANIP 

[-/> C (AND (=/> '(NODE-TERMINALS ?N1> ?T1) 
(»/> '(NODE-TERMINALS ?N2> ?T2)> 
(/:MOO-MANIP ?TASK (NOOES-MERGE ?N1 ?N2) 
<•(=/> '(NODE-TERMINALS ?N1> ?T1) 

'(=/> '(NODE-TERMINALS ?N2) ?T2)> 
<'(=/> '(NODE -TERMINALS ?NI) (UNION ?TI ?T2)) 
'(«/> '?N2 ?N1)>)1) 



t TERMINALS CAN BE CONNECTEO TO CREATE NEU NODES OR MERGE OLD ONES 

(DEFMLA TRMINS-CONNECT-DO-1 

{-/> C (AND (NODE-OF ?T1 >N1) (NOOE-OF ?T2 ?N2)> 
(/! TO-DO 7TRSK (TRMINS-CONNECT ?T1 ?T2) <> 
(NOOES-MERGE 'Nl >N2))J> 

(DEFMLA TRMINS-CONNECT-DO-2 

t-/> C (AND (NOOE-OF ?T1 ?N1) 
(CONSISTENTLY 

'(FORALL (N) (NOT (NOOE-OF ?T2 ?N)) )) 
(-/> '(NODE-TERMINALS ?N1) ?TS1>) 
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(/sMOD-MRNIP 'TASK (TRN1NS-C0NNECT ?T1 ?T2> 
<•(»/> ' (NODE-TERMINALS ?N1) ?TS1)> 
<•<=/> ' (NODE-TERMINRLS ?N1) <?T2 !#?TS1>)>)1) 

(OEFOLfl TRMINS-CONNECT-DO-3 

[-/> C (RNO (NOOE-OF >T2 ?N2> 
(CONSISTENTLY 

MFORRLL (N) (NOT (NOOE-OF ?T1 ?N>) )) 
<«/> ' (NODE-TERMINRLS ?N2) ?TS2)) 
</:MOO-MRNIP 7TRSK (TRMINS-CONNECT ?T1 ?T2) 
<'(=/> '(NODE-TERMINALS ?N2) ?TS2)> 
<•(,/> '(NODE-TERMINALS ?N2) <?T1 !f?TS2>)>)I) 

(OEFflLA TRI1INS-CONNECT-00-* 

{-/> C (BND (CONSISTENTLY 

'(FORALL (N) (NOT (NOOE-OF ?T1 ?N)> )> 
(CONSISTENTLY 

MFORRLL (N) (NOT (NOOE-OF ?T2 ?N>) ))) 
(/iMOO-MRNIP 7TRSK (TRMINS-CONNECT ?T1 ?T2) 
<> 
<* (EXISTS (N) 

(=/> * (NODE-TERM INRLS ?N) <?T1 ?T2>) )>)}) 



INSERTING R DEVICE INTO R NODE BREAKS IT INTO TUO NODES 
(OEFflLA DEV-INSERT 

C-/> C (RND (=/> '(NODE-TERMINRLS ?NODE) ?TS) 

(» (SET ?TS1) (SET <!#?TS1 !#?TS2>))> 
(/:HOO-nRNIP ?TRSK 

t (OEV-INSERT ?0 'NODE ?T1 ?TS1 ?T2 ?TS2) 
<'(«/> '(NODE-TERMINRLS 7NOOE) ?TS)> 
<'(=/> '(NODE-TERMINRLS 7NOOE) <?T1 !#?TS1>) 
'(EXISTS (NEHNODE) 

(RND (DEV-TYPE ?NEHNOOE NODE) 

(«/> ' (NODE-TERMINRLS ?NEUNOOE) 
<?T2 !#?TS2>)> )>)]) 

(DEFMLA PORT-DEFN CPRIMITIVE-OEV-TYPE PORT)) 

{PORTS CRRRY VOLTAGE OR CURRENT 

(DEFHLB PORT-TAXONOMY I XOR1 (DEV-TYPE 'X PORT) 

<<V-PORT ?X) (I-PORT ?X)>) 
GENERAL-OP*) 

(DEFOLA PORT-MEDIUn-l 

t-/> C (V-PORT ?X) (»/> ' (PORT-MEOIUH ?X> VOLTAGE)!) 

(DEFMLA PORT-MEDIUM-2 

t-/> C (I-PORT ?X> U/> '(PORT-MEDIUM ?X) CURRENT)]) 



;MOST PORTS ARE VOLTAGE PORTS 

(DEFMLA PRES-V-PORT [-/> C (AND (DEV-TYPE ?X PORT) 

(CONSISTENTLY * (V-PORT ?X>)) 
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(V-PORT ?X)J) 

I A NEST IS HADE UP OF PORTS AND IS ITSELF A PORT 

(DEFI1LA NEST-PORT !-/> fl (OEV-TYPE ?X NEST) (OEV-TYPE ?X PORT) J) 

(OEFHLB NEST-OF-1 t-/> A (./> • (NEST-PORTS ?N) ?TS) 

(-/> C (ELT ?T ?TS) (NEST-OF ?T ?N))1) 

(DEFflLA NEST-OF-2 IPRESUI1ABLY '(NOT (NEST-OF ?T ?N>) CI) 

j PORTS ARE HOMES FOR SIGNALS 

;KVL FOR PORTS 
(DEFflLA KVL-2 

I-/> A («/> ' (NEST-PORTS ?NEST> 7PORT-TUP) 
(-/> G (ELT 'PORT ?PORT-TUP> 

(AND (-/> A (SIGNAL-HOflE ?SIG ?PORT) 

(SIGNAL -HOHE ?SIG ?NEST))))1) 

(OEFtlLA SIGNAL -HOI1E 

!-/> A (SIGNAL -HOnE ?SIG 'PORT) 

(•/> '(PORT-SIGNAL ?PORT) ?SIG)J) 

; THESE ACTIONS ARE ANALOGOUS TO THE NODE ACTIONS 

(OEFHLA NESTS-HERGE-nANIP 

t-/> C (ANO (=/> • (NEST-PORTS 'Nl> ?T1) 
(•/> ' (NEST-PORTS ?N2> ?T2>) 
(/:MOD-t1ANlP ?TASK (NESTS-HERGE ?N1 ?N2) 
<' (»/> ' (NEST-PORTS ?N1) ?T1) 

'(=/> '(NEST-PORTS ?N2) ?T2>> 
<•(./> '(NEST-PORTS ?N1) (UNION ?T1 ?T2)) 
'<»/> '?N2 ?N1)>)1) 



(DEFHLA PORTS-CONNECT-OO-1 

I-/> C (AND (NEST-OF ?T1 >N1> (NEST-OF ?T2 ?N2>> 

</: TO-DO ?TRSK (PORTS-CONNECT ?T1 ?T2 ?TYPE) <> 
(NESTS-HERGE >N1 ?N2))I) 

(OEFHLA PORTS-CONNECT-00-2 

t-/> C (AND (NEST-OF ?T1 ?NI> 
(CONSISTENTLY 

'(FORALL (N) (NOT (NEST-OF ?T2 ?N)) )) 
(«/> '(NEST-PORTS ?N1) ?TS1>> 
(/lOOD-tlANIP 'TASK (PORTS-CONNECT ?T1 ?T2 7TYPE) 
<*(=/> '(NEST-PORTS ?N1) ?TS1)> 
<•(=/> '(NEST-PORTS ?N1) <?T2 !#?TS1>)>))) 



(OEFHLA P0RTS-C0NNECT-D0-3 

t-/> C (AND (NEST-OF ?T2 ?N2) 
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(CONSISTENTLY 

' (FORRLL (N) (NOT (NEST-OF ?T1 ?N>) )) 
<=/> '(NEST-PORTS >N2> ?TS2)> 
(/jflOD-HRNIP ?TRSK (PORTS-CONNECT ?T1 ?T2 'TYPE) 
<•(=/> '(NEST-PORTS ?N2) ?TS2)> 
<'<*/> '(NEST-PORTS ?N2) <?T1 !#?TS2>)>)J> 

(DEFflLfl PORTS-CONNECT-DO-* 

[-/> C (HMD (CONSISTENTLY 

'(FORRLL (N) (NOT (NEST-OF ?T1 ?N)) )) 
(CONSISTENTLY 

'(FORRLL (N) (NOT (NEST-OF ?T2 ?N)) ))) 
(/sHOO-HRNIP 'TASK (PORTS-CONNECT ?T1 ?T2 ?TYPE) 
<> 
<* (EXISTS (N) (=/> '(NEST-PORTS ?N) <?T1 ?T2>) )>)]> 



(DEFflLfl PORTS-CONNECT-DIRECT-DO 

(-/> C (RNO (PORT-TERHINRLS ?PRT1 <?T0P1 ?B0T2>) 
(PORT-TERHINRLS ?PRT2 <?T0P2 ?B0T2>) 
(OR (/:nOD-f1RNIP ?TfiSK (TRAINS-CONNECT ?TOPl ?T0P2) 
?DEL 'ROD) 
(/iHOD-HRNIP ?TRSK (TRHINS-CONNECT ?BOTl ?BOT2> 
?DEL ?RDD>)) 
(/:riOD-nRNIP ?TRSK (PORTS-CONNECT ?PRT1 ?PRT2 DIRECT) 
'DEL 'ROD))) 



(DEFflLfl PORTS-CONNECT-CRPRC I T I VE-DO 

t-/> C (RNO (PORT-TERHINRLS 'PRT1 <?TOPl ?BOTl>) 
(PORT-TERHINRLS ?PRT2 <?TOP2 ?BOT2>)) 
(/: TO-DO ?TSK (PORTS-CONNECT ?PRT1 ?PRT2 CRPRCITIVE) <> 
(CONFIG <CRPRCITOR> 
(\ (C) 

< (TRHINS-CONNECT (#1 ?C> >TOPl> 
(TRHINS-CONNECT (#2 ?C> ?T0P2)> ))))) 



(DEFflLfl PORTS-CONNECT-INDUCTIVE-00 

(-/> C (RND (PORT-TERMINALS 'PRT1 <?TOPl ?B0T1>) 
(PORT-TERHINRLS ?PRT2 <?T0P2 ?B0T2>)) 
</: TO-DO 'TSK (PORTS-CONNECT ?PRT1 >PRT2 INDUCTIVE) <> 
(CONFIG <TRRNSFORHER> 
(\ (LL) 
< (TRHINS-CONNECT (#2 ?LL) ?TOPl) 
(TRHINS-CONNECT (#4 ?LL) ?TOP2>> )))J) 

(SIGNALS 

(DEFflLfl FL-SHRPE CELT (FL-SHRPE ?LH) <HUf1P SPIKE>)> 

(DEFflLfl FF-FREQ [»/> * (FF-FREQ (FF ?F ?LM> ?FJ) 
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(DEFttLA FF-LANDHARK [-/> • (FF-LRNDHflRK <FF ?F ?L«>> ?LM> 



(OEFOLA PER100IC-FREQ-PIC 

[-/> C (PERIODIC ?S ?T> 

(«/> ' (FREQ-PICTURE ?S) 

(UNION (POSSIBLE-DC-SOB-PIC ?S) 
(SERIES-SUB-PIC ?S>>>]> 

(OEFflLA DC-FEATURE-1 

l-/> C (RNO (PERIODIC 7TFUN ?T) 

(» (OFFSET 7TFUN) ?V) 
(/> (RBS ?V> 9)) 
(-/> '(POSSIBLE-DC-SUB-PIC ?S» 

<(FF (OC-LRNOnRRK 7TFUN ?V)>>)1J 

(DEFHLA DC-FERTURE-2 

l-/> C (RNO (PERIODIC 7TFUN ?T> 
(* (OFFSET 7TFUN) 0)) 
(»/> * (POSSIBLE-DC-SUB-PIC ?S> <>)J) 

(DEFtlLB DC-LANDMARK -1 

[»/> ' (FL-SHRPE (DC-LRNDI1RRK ?TFUN ?V)) SPIKE! 
GENERAL -DP*) 

(OEFflLA DC-LRNOnRRK-2 

(=/> '(FL-HEIGHT (DC-LRNDflRRK ?TFUN ?V)) ?VJ 
GENERAL -OP») 



(DEFHLA FREQ-PIC-ELTS {IMPLIES (ELT ?X (FREQ-PIC ?S)) 

(IS FREQ-FERTURE ?X)1) 

(DEFMLA SPIKES 

l-/> A (PERIODIC 7TFUN ?T) 

(FORRLL (X) (-/> C (ELT ?X (FREQ-PICTURE 7TFUN)) 
(• (FL-SHRPE ?X> SPIKE) > )I) 



(DEFDLA SINUSOIDAL-SPIKE 

[-/> C (AND (PERIODIC ?TFUN ?T) 
(SINUSOIDAL >TFUN) 
(RMPLITUOE ?TFUN ?R)) 
(•/> '(SERIES-SUB-PIC ?TFUN> 

<(FF (SIN-LRNDHRRK 7TFUN ?T ?B))>)1) 

(OEFflLA EVERYOTHER-SERIES 

I-/> C (RNO (PERIODIC ?TFUN ?T) 

(NOT (SINUSOIORL ?TFUN>> 
(FORRLL (X) 

U (7TFUN ?X> (7TFUN (♦ ?X (// ?T 2)))) )) 
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U/> • (SERIES-SUB-PIC ?TFUN) 

(SERIES <* 2 PI (// 1 ?T)> (* * PI <// I ?T») 
SPIKE 
(\ (M) 

(INTEGRAL 8 ?T 
(\ (U) 

(* (?TFUN ?U) 

(COS (♦ 2 PI <- <* 2 ?N> 1) 

?U (// 1 ?T>>>> )) ) 
))I) 



(OEFHLR STRRIGHT-SERIES 

l-/> C (AND (PERIODIC ?TFUN ?T> 

(NOT (SINUSOIOAL >TFUN>) 
(EXISTS (X) 

(NOT (« (7TFUN ?X> 

(?TFUN (+ ?X (// ?T 2))))) )> 
(»/> '(SERIES-SUB-PIC ?TFUN) 

(SERIES (* 2 PI (// 1 ?T>) (♦ 2 PI <// 1 ?T>> 
SPIKE 
(\ (N) 
( INTEGRAL 8 ?T 
(\ (U) 

(* (?TFUN ?U) 

(COS (* 2 PI ?N 

?U (// 1 ?T)))) )) ) 
>>]> 

(OEFm.Fl SIN-LRNOdARK-SHAPE 

t«/> ' (FL-SHAPE (SIN-LANDtlARK ?TFUN H ?fl)> SPIKED 

(DEFtlLR SIN-LRNDflARK-HEIGHT 

L/> MFL-HEIGHT (SIN-LANOHARK ?TFUN ?T ?R>> ?R1> 



(DEFIILR SINU+ l-/> C (AND (ELT ?SIN ?FS) 

(SINUSOIOAL ?SIN) 
(FORflLL (F> 
(EXISTS (R) 

(IMPLIES (ELT ?F (OEL ?SIN ?FS)) 
(/i* ?F (K 1 ?R))) ))) 
(SINUSOIDAL (CUP + ?FS)>)> 

(DEFHLR SINU* {-/> C (RNO (ELT ?SIN >FS> 

(SINUSOIDAL ?SIN) 
(FORflLL (F) 
(EXISTS (B> 

(ItlPLIES (ELT ?F (OEL ?SIN ?FS)) 
(/!, ?F (K 1 ?R>>> )•)) 
(SINUSOIDAL (CUP • ?FS>>)> 

(OEFULR SIN-SIN [-/> C (LINEAR ?F) 
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(SINUSOIDAL (CUP SIN <?F>>>]> 

(OEFflLfl COS-SIM t-/> C (LINEAR ?F> 

(SINUSOIDAL (CUP COS <?F>))1) 

(DEFMLA LIN1 ILINEAR (IDN ?N ?K>1> 

(OEFNLfl LIN2 [-/> C (AND (ELT ?LIN ?FS> (LINEAR ?LIN) 

(FORALL (K) 
(EXISTS (A) 

(IMPLIES (ELT ?K (DEL ?LIN ?FS)> 
(/«« ?K (K 1 ?A))) ))) 
(LINEAR (CMP * ?FS))J) 

(DEFMLA LIN3 [-/> C (FORALL <F) (IMPLIES (ELT ?F ?FS) (LINEAR ?FM ) 
(LINEAR (CMP + ?FS))J> 

(DEFMLA LIN* t-/> C (LINEAR (CMP + <?Fi (\ (X) (- (?F2 ?X>> )>)) 
(LINEAR (CMP - <?F1 ?F2>>»> 

(OEFHLA LIN5 t-/> C (AND (LINEAR ?F1> 

(/!* ?F2 (K 1 ?fl>)) 
(LINEAR (CMP // <?F1 ?F2>>)I) 

(OEFHLA SIN-PERIODIC (PERIODIC SIN (* 2 PI>}> 

(OEFMLA COS-PERIODIC [PERIODIC COS (* 2 PDI) 



(DEFMLA PRES-NOT-SIN (PRESUMABLY '(NOT (SINUSOIDAL ?F>> CI) 

(OEFMLA OFFSET-OEFN [-/> A (PERIODIC ?TFUN ?T) 

(«/> ' (OFFSET ?TFUN> 

(// (INTEGRAL 9 ?T ?TFUN) ?T))I> 

jUNEAR-DERIVEO MODELS 

j (ISOLATE Tl T2) IS A MORLO IN UHICH THE CIRCUIT IS DECOUPLED 

(DEFMLA REF-ISO (IS REF (ISOLATE 7TRHIN1 HRHIN2>1> 

(DEFMLA FRAME-ISO [(FRAME (ISO ?TRMIN1 ?TRMIN2) <(HERE)>)I) 

(DEFMLA ISOLATE -OEFN-1 

(-/> C (AND (./> ' (NOOE-TERMINALS ?N1) 

<!#?TSH ?TRMIN1 !#?TS12>) 
(»/> ' (NOOE-TERMINALS ?N2) 

<!#?TS21 ?TRMIN2 !#?TS22>>) 
(T (ISOLATE ?TRHINI ?TRMIN2) 

(AND (-/> '(NODE-TERMINALS ?N1) 
<!#?TSU !#?TS12>) 
(»/> '(NODE -TERMINALS ?N2> 
<!#?TS21 !#?TS22>)))1) 
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(OEFtlLfl 1SOLATE-DEFN-2 

t-/> C (»/> ' (NOOE-TERNINALS ?N1) 

<!#?TS11 ?TRMINI i#?TS12>) 
(N (ISOLATE 7TRMIN1 ?TRMIN2) 
*(./> '(NODE-TERMINALS ?M1) 

<!f?TSll 'TRMIN1 !#?TS12>))J> 

<defhla isolhte-defn-3 

t-/> C (=/> ' (NODE-TERM INflLS ?N2) 

<!#?TS21 ?TRf1IN2 !J?TS22>) 
(H (ISOLRTE HRMIN1 7TRNIN2) 
• (./> ' (NODE-TERMINRLS ?N2> 

<!#?TS21 7TRNIN2 !#?TS22>>») 



jFOR THE FOLLOUING REFERENCE-POINT DEFINITIONS, 

I SEE CIRCUIT POCKETS FOR ALTERED COMPONENT PROPERTIES IN EACH REF 

(DEFULA REF-DC IIS REF (DC))) 

(DEFriLfl FRAME -OC I (FRAME (DC) <(HERE)>)1) 



(DEFflLA REF-SSS tIS REF (SSS 7FREQ))) 
(DEFflLA FRAHE-SSS KFRAHE (SSS ?S> <(HERE)>)J) 

(DEFflLA REF-INC (IS REF (INC) J) 

(OEFHLA FRAME-INC ((FRAME (INC) <(HERE)>)I) 

(OEFriLA REF-PASSIVE IIS REF (PASSIVE) J) 

(DEFflLA FRAME-PASSIVE ((FRAME (PASSIVE) <(HERE)>>)> 

{INTERACTIONS — 

jTHIS tlEANS (T (DC) (DO) = (DC) 

(OEFflLA DC-IDEM IREF-IOEMPOTENT (OC)l) 

(DEFflLA ISOLATE-IOEtl IREF-IOEMPOTENT (ISOLATE 7TRHIN1 ?TR(1IN2))> 

(DEFflLA - SSS- 1 OEM IREF-IOEMPOTENT (SSS ?S)I) 

(DEFflLA PASSIVE-IDEM IREF-IOEMPOTENT (PASSIVE))) 

(DEFflLA INC-IOEM IREF-IOEMPOTENT (INC))) 



(OEFULR OC-ISO t./> ' (T (DC) (ISOLATE 7TRHINI 7TRMIN2)) 
(T (ISOLRTE ?TRMIN1 7TRMIN2) (OC)))> 
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(OEFtlLA PASSIVE -DC (./> ' (T (PASSIVE) (0C>> (T COO (PASSIVE)))) 



(INFORMATION ABOUT REPHRASING ELECTRONIC OESICN PROBLEHS 

(O-SHAROS ARE FRAGMENTS OF OESICN PROPERTIES| THOSE DEALING HITH 
f CONTROL QUANTITIES ARE IMPORTANT 

; THESE APPLY TO "10" DEVICES 

(DEFULA CQ-V-GAIN tGENERIC-CA V-GAINJ) 
(OEFflLA CQ-P-GAIN IGENERIC-CA P-GAINJ) 
(DEFflLA CQ-I2 tGENERIC-CA INPUT-ZJ) 
(OEFflLA CQ-OZ IGENERIC-CA 0UTPUT-Z1) 



(DEFHLA V-GAIN-SHARO 

!-/> A (O-SHARD ?+P (\ <_? + V) (. (V-GAIN <|??| _?+V)) 

_?+G)l> 
(ANO (SIDE-TASK ?+P 

(\ (_?+V> 

(CONSTRAIN <* (V-GAIN (|??| _?+V>>> 
(\ (Gl) (• ?G1 _?+G) ))J> 
(-/> G (. (OEM ?+G) ?G> 

(ANO (-/> G (/> ?G 1886) 

(D-FEATURE 7*P 

(RANGER V-GAIN VERY-HIGH))) 
(-/> G (ANO (/> ?G 51) 

(/< ?G 5888)) 
(D-FEATURE ?+P 

(RANGER V-GRIN HIGH))) 
(-/> G (ANO (/> ?G 1) 

(/< ?G 188)) 
(P-FEATURE ?+P 

(RANGER V-GAIN MODERATED) 
(-/> G (*/< ?C 1) 

(O-FEATURE ?+P 

(RANGER V-GAIN LOU)))))))) 



I "GAIN" ALONE MEANS V-GAIN AND P-GAIN 
(OEFHLA GAIN-SHARD 

(-/> A (D-SHARO ?*P l\ (_'+V) (- (GAIN (|??| _?+V)> 

(ANO (O-SHARD ?+P (\ (_?+V) (, (V-GAIN (|??| _?+V>> 

_?+G)I) 
(-/> G (AND (. (* 28 (LOG (DEN _?+G>>) ?PG) 
(CONVERT TO OECIBELS 
(= (DEN ?+PG> ?PC>) 
(0-SHARO ?+P 
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(\ (_?+V) (. (P-GAIN (|??| _?*v>) 
_?+PC)J)))J) 



(OEFriLfl INPUT-Z-SHARD 

l-/> A (D-SHARD ?+P [\ (_?+V> <» (INPUT-2 (|??| _?+V>> 

_?+Z>)> 
(-/> & (. (OEN ?+Z> ?Z) 

(AND (-/> C (/> ?Z 3.8E5) 
(D-FEATURE ?+P 

IRflNGER INPUT-Z VERY-HIGH))) 
(-/> G (AND (/> ?Z 1.5E3) 
(/< ?Z 5.8E5)) 
(O-FEATURE ?+P 

(RRNGER INPUT-Z HIGH))) 
(-/> G (AND (/> ?Z 588) 

(/< ?Z 2.8E3)) 
(O-FEATURE ?+P 

{RANGER INPUT-Z HOOERATE1 ) ) 
<-/> G (/< ?2 1888) 

(D-FEflTURE ?+P 

[ RANGER INPUT-2 LOW ))))!) 



(DEFHLfl OUTPUT-Z-SHRRD 

t-/> fl (O-SHflRO ?+P I\ (_?+V> (« (OUTPUT-Z <|??| _?*V>) 

_?+Z)l) 
(-/> G (» (OEN >+Z> ?Z) 

(AND (-/> G (/> ?Z 1.8E6) 
(D-FEATURE ?+P 

[RANGER OUTPUT-Z VERY-HIGH))) 
(-/> G (AND (/> ?2 1.8E5) 
(/< 1.5E6)) 
(D-FEflTURE ?+P 

[RANGER OUTPUT-2 HIGH))) 
(-/> G (AND (/> ?2 l.BE*) 
(/< '2 1.SE5)) 
(O-FEHTURE ?+P 

[RANGER OUTPUT-2 HOOERATE))) 
(-/> G (AND (/> ?2 188) 

</< ?Z 1.5E4)) 
(D-FEATURE ?+P 

[RANGER OUTPUT-Z LOU))) 
(-/> G (/< ?Z 288) 

(D-FEflTURE ?+P 

[RANGER OUTPUT-Z VERY-LOM) )>>>)> 
{SOURCE: UATSON (1978), P. 68 



(SHARDS REGARDING SIGNAL CONVERSIONS tlUST BE EXPLOOEO SPECIALLY 



(DEFHLA CONVERT-EXPLOOE 

t-/> fl </i TASK-ACTION ?T (O-EXPLOOE ?+P)) 
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(-/> n 

(0-SHRRO >+P 
IV (_?+V> 

(CONVERT (|??| _?+V) _?+Q _?+R))) 
(EXISTS (Tl> 

(AND (STASK ?T1 ?T <> 

(\ () (CVT-EXPLOOE ?+Q ?+R) ) 
<>> 
(/:HAIN ?T1 ?T) 

(-/> A (SIG-FEATURE 7+0. ?+R ?*FEATURE> 
(D-SHARD ?*P 
t\ (_?+V) 

(SIG-TRHNS _?+V 

_?*FEATURE>]>>> )>) 
GENERAL -OP*> 

I THERE RRE TUO URYS TO DO THIS— 

(OEFHLB CVT-EXPLOOE-1 

t/iTO-00 ?THSK (CVT-EXPLOOE >+Q ?+R> <> 
(FREQ-DOtlAIN-REPHRASE ?+Q ?+R)J) 

(DEFflLA CVT-EXPLOOE-2 

t/: TO-DO 'TASK (CVT-EXPLOOE ?+Q ?«.R) <> 
(TinE-OOHRIN-REPHRflSE '+0 ?+R)J) 

» BASIS ON UHICH TO CHOOSE ONE OR THE OTHER 
(DEFHLR CVT-CHOICE 

C/iflNTEC (NOT (/:CHOICE ?C EXEC 
(/: TO-DO _?+TASK 

(CVT-EXPLOOE _?+*Q _?♦♦!» <> 
_?++f1ETH001>> 
(-/> A (/:0PT10N ?C ?fll 

t/i TO-DO _?+TRSK 

(CVT-EXPLOOE _?++Q _?++R) 
<> 

(FREQ-OOHRIN-REPHRASE 
J**Q _?+*R>]> 
(-/> fl (/: OPTION ?C ?R2 
t/s TO-DO _?*TASK 

(CVT-EXPLOOE J+*Q J++H) 
<> 

(TIHE-DOflAIN-REPHRASE 
_?++Q _?*+R)J) 
; IF OUTPUT RELATION DOESN'T MENTION INPUT, TAKE FREQUENCY-OOflAIN 

(AND (-/> G (AND (/«. (DEN ?t*R) 

t\ (_?+SVl _?+SV2) 
_?4B00YJ ) 
(NOT (CONTAINS ?+BOOY 

I |?? | _?*SV1J)>» 
(/:RULE-IN ?A1)> 
f IF INPUT PREDICATE IS TRIVIAL, TAKE TME-OOflAlN 

(-/> G (AND </i« (DEN ?++Q> 
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[\ (_?+V> _?+BODYJ) 
(NOT (CONTAINS 7+BOOY 
t|??| _?+V)>)> 
(/:RULE-IN ?A2>> 
I FOR VERY HIGH FREQUENCIES, TIME OOHAIN UON'T UORK 

<-/> G (AND (ASUBTASK (DEN '*TASK> 
?SUP) 
(/s TASK -ACTION ?SUP 

(O-EXPLODE ?+P>) 
</». (/sENAB-STATUS 
?SUP) 
ACTIVE) 
(0-FEATURE ?+P 
[RANGER FREQ-OP 

VERY-HIGH) >> 
(/sRUlE-OUT ?A2)>>>)] 
GENERAL -OP«> 

I FREQUENCY-DOHA IN REPHRASING INFO 

(DEFI1LA FREQ-DOF1-REPH-DO-1 

1/jTO-DO ?TASK (FREQ-DOnAIN-REPHRHSE ?+Q ?+R) <> 
(/sSEQ 
(/:FINO 

(\ (+FPT) 

(EXISTS (FP1 FP2 FPT) 
(FORALL (SI S2> 

(IMPLIES (AND (IS SIGNAL ?S1) 
((DEN ?+Q> ?S1) 
(IS SIGNAL ?S2) 
((DEN ?+R> ?S1 >S2)) 
(AND (•/> * (FREQ-PICTURE 
(TFUN >S1>> 
?FP1) 
(./> MFREQ-PICTURE 
(TFUN ?S2>> 
?FP2> 
(FREQ-PIC-TRANS ?FP1 ?FP2 

?FPT) 
(./> *(0EN ?+FPT) ?FPT)>) 
>>>) 
(\ (FPT) 

(/! INFER ' (SIG-FEATURE ?+Q ?+R [FREQ-TRANS _?*FPTI) 
<>) )))) 



(GENERATING FREQUENCY-DOHAIN TRANSFORATIONS 



(OEFtlLR NFREQ-PICS-FILTER 

C/iCONSEQ (NOT (FREQ-PICS-FILTER ?FP1 

<(FF ?FREQ ?LH2) !#?FP2> ?C)) 
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(HOT (FORALL (LH1) 

(MOT (ELT (FF ?FREQ ?L(11) ?FP1>> )>}) 



(DEFflLB FREQ-TRANS-LOU 

I/iCONSEQ (FREQ-TRANS 7FP-1N 7FP-OUT (LOU-PASS ?H)) 

(NOT (AND (FREQ-PICS-FILTER ?FP-IM 7FP-OUT 7FP-GONE) 
(FORALL (FL F) 

(ANO (EQUIV (ELT (FF ?F ?FL> 7FP-GONE) 
(FORflLL (FL1 Fl) 
(IHPLIE8 (ELT (FF ?FI ?FL1) 
?FP-GONE) 
(/> ?F ?F1)> )) 

(/!» ?n 

(HflX 7FP-GONE 
(\ (F G) 
(/> (FF-FREQ ?F) 
(FF-FREQ ?G)) 
)))) )))]) 

;SIMLARLY FOR HIGH-PASS AND BHNO-PASS 

(OEFHLR FREQ-PICS-FILTER-1 

[FREQ-PICS-FILTER ?FP1 <> 7FP11) 

(OEFHLA FREQ-PICS-FILTER-2 

t/rCONSEQ (FREQ-PICS-FILTER ?FP1 <(FF 7FREQ 7LH2) !#?FP2> 7C) 
(NOT (ANO (ELT (FF ?FREQ 7LH1) ?FP1) 

<« (FF-SHAPE ?LM> (FF-SHAPE ?LH2)> 
(FREQ-PICS-FILTER (DEL (FF 7FREQ 7LM> 7FP1) 
?FP2 ?C>>>)) 

(TYPES OF FREQ-TRANSi (LOU-PASS |CUTOFF|), (HIGH-PASS |COTOFF|), 
j (BAND-PASS |CUTOFF|), (MX |SIGNAL-PREO|) (NOOULRTE...) 

(OEFHLA LOU-PASS 

t/iANTEC (NOT (0-SHARO ?+P 

I\ (_?*V> (SIG-TRANS (|?7| J+V) 
(FREQ-TRANS 

(LOU-PASS _?+CUTOFF>))J>> 
(CORE-DEV-TYPE ?*P ILOU-PASS-FILTER _?+CUTOFFI > ) > 

(OEFflLA HIGH-PASS 

t/tANTEC (NOT (D-SHARO 7+P 

l\ (_?+V> (SIG-TRANS (|??| _?+V> 
(FREQ-TRANS 

(HIGH-PASS _?+CUTQFF)>>]>> 
(CORE-DEV-TYPE 7+P (HIGH-PASS-FILTER _?+CUTOFFJ)J> 



j CHOOSING DEV-TYPES ~ 
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(OEFMLR LINERR-GROUPING 

t-/> fl (/:CHOICE ?C ?TSK tCORE-DEV-TYPE _?++P _?+*OI) 
<-/> fl (QUIESCENCE ?C) 

(-/> G (AND (/:OPTION ?C ?fll 
[CORE-OEV-TYPE 

C ?**P) t_?++DlH) 

(/! OPTION ?C ?A2 

[CORE-OEV-TYPE t_?*+Pl t_?+*021)> 
(LINERR-DEV-TYPE (DEN (DEN ?++02)>> 
> 
(/! RULE-TOGETHER <?A1 ?A2> 
tCORE-DEV-TYPE _?++P 

(GROUP <_?++Dl _?-f+02>>))>M> 



I CROUPS MRY BE EXPRESSED RS SEVERAL KINDS OF CASCADE 

(DEFULfl riAKE-GROUP-1 
t/:CONSEQ 

(/s TO-DO ?T (MAKE (GROUP <?X ?Y !#?Z>>> <?NRME> 
(/:SEQ (ACQUIRE (GROUP 'OT-REST)). 

<\ (G) (MRKE (CRSCAOE ?DT1 ?G>) >)> 
(NOT (AND (ELT ?DT1 <?X ?Y !#?Z>) 

(/:» 7DT-REST (DEL ?DT1 <?X ?Y !#?Z>))))J 
GENERAL-DP*) 



(DEFHLA nAKE-GROUP-2 

t/:TO-00 ?T (MAKE (GROUP <?OTl ?DT2>>) <?NAME> 
(HAKE (CASCADE ?OTl ?DT2))J) 

(DEFHLA HAtCE-GROUP-3 

l/s TO-DO ?T (MAKE (GROUP <>OTl ?DT2>>> <?NAHE> 
(HAKE (CASCADE ?OT2 ?DT1>>]) 

lAMPLIFIER IS A UIDE ("SUPERORDINATE") CATEGORY, FOR UHICH THERE ARE 
I SEVERAL SPECIFIC TYPES 

(DEFHLA AHP-DEV-TYPE (SUPERORDINATE-OEV-TYPE AHPLIFIERI) 

(DEFHLA SUB-CE ISUB-DEV-TYPE CE AMPLIFIER] ) 
(OEFMLA SUB-CC [SUB-DEV-TYPE CC AMPLIFIER)) 
(DEFMLA SUB-CB ISUB-OEV-TYPE CB RMPLIFER)) 

5 IF nODERATE V-GA1N, COMMON EMITTER 
(DEFHLA MOO-V-GAIN 

(-/> A (/s TASK-ACTION 'TSK (MAKE AMPLIFIER)) 
(-/> A (/i SCOPE ?PTSK ?TSK> 

(-/> A (/POLICY ?PTSK 

(O-NOTE (RANGER V-GAIN MODERATE))) 
(/sTO-OO ?TSK (MAKE AMPLIFIER) <?OEV> 
(MAKE CE))>)) 
GENERflL-DP*) 
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t IF HIGH V-CflIN, SOHE KIND OF N-STAGE 
(OEFflLA HIGH-V-GRIN 

l-/> fl (/t TASK-ACTION ?TSK (MAKE AMPLIFIER)) 
(-/> fl (/! SCOPE ?PTSK ?TSK) 

(-/> fl (/i POL ICY ?PTSK 

(O-NOTE (RANGER V-GflIN HIGH))) 
</s TO-DO ?TSK (IWKE HHPLIFIER) <?OEV> 
(MAKE N-STAGE))))) 
GENERAL-DP*) 



t IF VERY-HIGH, OP-AHP 
(DEFttLfl VERY-HIGH-V-GAIN 

[-/> R </: TASK-ACTION ?TSK (HAKE AHPLIFIER)) 
(-/> A (/tSCOPE ?PTSK ?TSK) 

<-/> A (/iPOLICY 7PTSK 

(D-NOTE (RANGER V-GflIN VERY-HIGH))) 
(/: TO-DO ?TSK (HAKE AMPLIFIER) <?DEV> 
(HAKE OP-AHP))))! 
GENERAL -OP*) 



; IF VERY LOM FREQ OF OPERATION (E.G., DC) — OIFF AOP 
(DEFALK VERY-LOU-FREQ 

!-/> fl (/! TASK-ACTION ?TSK (HAKE AMPLIFIER)) 
(-/> fl (/sSCOPE ?PTSK HSK) 

<-/> A (/tPOLlCY ?PTSK 

(O-NOTE (RANGER FREQ-OP VERY-LOU))) 
(/:TO-00 ?TSK (HAKE AMPLIFIER) <?OEV> 
(HAKE DIFF-AMP>>>» 
GENERAL -DP*) 



jIF HIGH INPUT Z, UP CC 
(DEFtlLfl HIGH-INPUT-2 

t-/> fl (/i TASK-ACTION ?TSK (HAKE AMPLIFIER)) 
(-/> fl (/iSCOPE ?PTSK ?TSK) 

(-/> fl (/iPOLICY ?PTSK 

(D-NOTE (RANGER INPUT-Z HIGH))) 
(/! TO-DO ?TSK (HAKE AMPLIFIER) <?0EV> 
(HAKE CO)))] 
GENERAL -DP*) 



t IF HIGH POUER GAIN, UP C.OHP-SYH AND PUSH-PULL 
(OEFHLA HIGH-POUER-GAIN 

[-/> fl (/:TASK-ACTION ?TSK (HAKE AMPLIFIER)) 
<-/> fl </: SCOPE ?PTSK ?TSK) 

(-/> A (/:POLICY ?PTSK 

(D-NOTE (RANGER P-GAIN HIGH))) 
(AND (/sTO-DO ?TSK (HAKE AMPLIFIER) <?DEV> 
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(MAKE CONP-SYH)) 
(/:T0-00 ?TSK (HAKE AMPLIFIER) <?0EV> 
(HRKE PUSH-PULL) >)>)] 
GENERAL -OP*) 



;IF LINEARITY REQUIREO, CE 
(DEFflLA LINEARITY 

[-/> A </: TASK-ACTION ?TSK (MAKE AMPLIFIER)) 
(-/> A (/: SCOPE ?PTSK ?TSK> 

(-/> A (/s POL ICY ?PTASK ?TSK 
(O-NOTE LINEAR)) 
(/s TO-DO ?TSK (MRKE AMPLIFIER) <?OEV> 
(HAKE CE))))) 
GENERRL-OP*) 

I IF MORE THAN ONE TYPE APPEARS, A CHOICE IS IN ORDER 

(OEFtlLH CHOOSE-RHP 

(-/> A (/:CHOICE ?C EXEC 

t/s TO-DO _?+TRSK (MAKE AMPLIFIER) <_?+NAHE> 
_?+METH0D) ) 
(-/> G </:. (DEN ?+TASK) ?AMP-TASK) 
(RND • 

(/iPKT CHOOSE-RHP-PKT 

<?C 'RMP-TASK ?«JASK 7+NAHE ?+HETHOD) 
(-/> A (/iQUIESCENCE ?C) 

</:PKT QUI-CHOOSE-ANP-PKT 
(?C 7AMP-TASK 7+TASK 
?+NAHE 7+NETHOD)))) 
(-/> G (/: SCOPE ?PTSK 7AMP-TASK) 
TRUE)))! 
GENERRL-DP*) 



j IF HIGH POWER RND LINEARITY ARE REQUIREO, REPLACE POUER-AHP 
I OPTION MITH LINEARIZED POUER-RMP 

(OEFtlLA LINEAR-POUER 

[-/> A (/: SCOPE 'PTSK1 ?RMP-TASIC) 

<-/> G (AND (/:POLICY ?PTSK1 (D-NOTE LINEAR)) 
(/: SCOPE ?PTSK2 7RNP-TRSK) 
(/:POLICY 'PTSK2 

(D-NOTE (RRNGER P-GAIN HIGH))) 
(»/> '(DEN 7+PTSK2) ?PTSK2)> 
<-/> A (/:OPTION ?C ?fll 

[/: TO-DO _?+TRSK (MRKE AMPLIFIER) 
<_?+NAHE> (HAKE _?+OT>)> 

<-/> G 

(OPT-SUPPORT ?R1 

t/: POLICY _?+PTASK2 
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_>flBOVE-ACTl ) 
(/(RULE-TOGETHER <?R1> 

l/iTO-00 _?*TRSK (HRKE RHPLIFIER) 
<_?*NAME> 
(/iSEQ (HAKE _?*DT) 
(\ (?X> 
(/(DO-ALL 
<(LINERRIZE ?X>> 
(/(OUTPUT <?X>>> ) 



)]>)>>] 

CHOOSE-n(1P-PKT) 



{QUIESCENCE PKT 

{DIFFERENTIAL DIAGNOSIS BETUEEN CE RNO N-STRGE 
(DEFHLB DIFF-CE-N-STAGE 
t-/> A (/! QUIESCENCE ?C> 

(-/> G (RNO (/(OPTION ?C ?fll 

l/iTO-00 _?+TRSK ((1RKE (WIPLIFIER) <?_+NRHE> 
ttlfltCE CE>]> 
(/(OPTION >C ?R2 

I/( TO-DO _?+TRSK (Hfltt RHPLIFIER) <_?+NAriE> 
(HAKE N-STAGE)J>> 
(RND 

(-/> G (RND (/: SCOPE ?PTSK ?AHP-TASK> 
(/i POL ICY ?PTSK 
(D-NOTE 

(RRNGER BRNDHIOTH HIGH)))) 
</: RULE-OUT 'Rl)> 
(-/> G (NOT (EXISTS (PTSK) 

(AND (/.SCOPE ?PTSK 7RNP-TRSK) 
(/i POL ICY ?PTSK 

(O-NOTE (RRNGER BRNOUiOTH 

HIGH)))) )) 
(/: RULE-OUT ?A2))))I 
CHOOSE-RHP-PKT) 



{IF ONE OPTION MRS SUGGESTEO BECAUSE OF ITS INPUT-Z (E.G., 
{ COntlON-COLLECTOR), AND ANOTHER FOR SOMETHING ELSE, 
j YOU HAY CASCADE THEH 



(DEFHLfl INPUT-CASCADE 

t-/> R (/(OPTION ?C ?R1 

I/iTO-DO _?+THSK (HAKE RHPLIFIER) <_?+N> 
(HRKE _?+OTl)J) 
(-/> G (OPT-SUPPORT ?fll 

I/iPOLICY _?+PTRSK 

(O-NOTE (RRNGER INPUT-Z _?+RRN))l) 
(-/> R 

(/(OPTION ?C ?A2 

l/(TO-00 _?+TRSK (HAKE AMPLIFIER) <_?+N> 
(HAKE _?+DT2H) 
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(-/> C (NOT U ?AI ?R2>) 

(/: RULE -TOGETHER <?fll ?R2> 

I/iTO-00 _?+TRSK (HAKE RHPLIFIER) 
<_?+N> 
(HAKE (CASCADE _?+DTl 
_?+0T2 
)))))))) 



CHOOSE-RtlP-PKT) 



(OEFflLfl OPT-SUPPORT t-/> C (AND (/: OPTION-SUPPORT ?OPT ?FflLRS) 

(ELT '+F ?FHLAS) 
(OR (:. ?+F ?+S> 

(SUPPORTS ?+S ?+F))> 
(OPT-SUPPORT ?OPT ?+S)J 
GENERAL-OP*) 

(OEFHLR SUPPORT-DEFN t-/> C (RND (/:DO ?+S ?P ?I ?+F2> 

(OR (:» ?+Fl ?+S) 

(SUPPORTS ?*F1 ?*S)>> 
(SUPPORTS ?+Fl ?+F2)J 
GENERAL -DP#> 



(DEFtlLfl HAKE-CASCADE 

t/i TO-DO ?TASK (HRKE (CRSCROE ?DT1 ?0T2>> <?NEUDEV> 

</:00-SUBNET (CRSCRDE-PLRN ?DT1 ?OT2) <CASCRDE-NRHE>>J> 



(DEFULA CRSCRDE -PLAN-NET 

t-/> R (/:PLRN-INSTANCE 'PJ (CASCADE-PLAN ?0T1 ?OT2) ?SUP) 
(AND (STRSK (HRICER-1 'PI) ?SUP <> 

(\ () (HAKE ?DT1) ) <'(FIRST-DEV ?PI)>) 
(STASK (HAKER-2 'PI) ?SUP <> 

(\ () (MAKE ?0T2) ) <• (SECOND-DEV ?PI)>) 
(STASK (GRABBER 'PI) ?SUP <> 
(\ () 

(GRflBBR (\ (X) 

(HRIN-DEV-TYPE 

?X (CRSCRDE ?DT1 ?DT2)) )) ) 
<'(CASCADE-NAHE ?PI)>) 
(STASK (COUPLER ?PI) ?SUP 

<MFIRST-DEV 'PI) • (SECONO-DEV ?PI)> 
(\ (Dl 02) (COUPLE ?DI ?D2) ) 
<>) 
(STASK (COttPONENTS-NAflER ?PI> 
<' (CASCADE -NRHE ?PI) 
'(FIRST-OEV 'PI) '(SECONO-OEV ?PI)> 
(\ (C Dl 02) 

(/: INFER • (COMPONENTS ?C <?01 ?02>) <>) ) 
<>) 
(/rHAIN (GRABBER 'PI) ?SUP))J 
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GENERAL -DP*) 



lUSE THE HOST GENERAL VERSION OF R CIRCUIT IN R CASCAOE 

(OEFflLA COUPLE-GENERAL-1 

l-/> fl (/(CHOICE ?C EXEC 

t/i TO-DO (tWKER-1 _?*PI> (HRKE _?*DT> <_?+DEV> 
_?+HAY] ) 
(-/> G (RND (=/> • (OEN ?+OT> ?DT) 

(HOST-GENERRL-SPEC ?OT ?SPEC-OT) 
(«/> '(OEN ?+SPEC-OT> 7SPEC-OT)) 
(-/> A (/i OPTION ?C ?A 

t/:TO-00 (flAKER-l _?+PI) (HAKE _?+OT> 
<_?*OEV> 
(HAKE _?+SPEC-OT)J) 
(/sRULE-IN ?fl)))J) 



(DEFflLA COUPLE-GENERRL-2 

!-/> R (/:CHOICE ?C EXEC 

l/i TO-DO (MAKER-2 _?+PI) (HRKE _?+DT> < ?+DEV> 
_?+WAY] ) 
(-/> G (RND <*/> • (OEN ?+OT> ?DT) 

(HOST-GENERRL-SPEC ?OT 7SPEC-OT) 
(»/> '(DEN ?+SPEC-DT> ?SPEC-OT>) 
(-/> fl (/:OPTION ?C ?fl 

l/> TO-DO (HAKER-2 _?+PI> (HRKE _?+OT> 
<_?+OEV> 
(HAKE _?+SPEC-OT)I) 
(/:RULE-IN ?A>>>)) 

jCIRCUIT ALTERATION ACTIONS 



(DEFHLA FIXING-CHANCES-TOPOLOGY (TOPO-CHftNGE-ACTION-FUN FIX!) 



(DEFHLA VS-FIX-V 

1/ : TO-DO ?TRS(C (FIX '(V 'NODE)) <> 
(CONFIG (VOLTAGE-SOURCE) 
(\ (VS) 
<(TRt1 INS-CONNECT (#1. ?VS> ?NODEJ> ))J) 



(DEFflLA VD-FIX-V 

t/«TO-00 ?TRSK (FIX '(QUIESCENT (V ?NODE>>> <> 
(CONFIG <VO NOOE NODE> 
(LRflBDfl (VO Nl N2) 

<(CONSTRAIN <'(V ?N1) '(V ?NOOE>> 

(\ (VI V) (/> ?V1 ?V) )) 

(CONSTRAIN <'(V ?N2) ' (V ?NOOE)> 

(\ (V2 V) (/> ?V ?V2) )) 
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(NODES-OERGE ?N1 (TOP ?VD>> 

(NODES-MERGE ?N2 (BOT ?VD>) 

(NODES-MERGE 'NODE (I1IO ?V0))> >)) 
GENERAL-DP*) 



(DEFULA DIF-FIX I/tTO-DO 'TASK (FIX * (- >X1 ?XZ>) <> 

(/:00-RLL <(FIX '?X1) (FIX »?X2)>)]) 

I BIASING 

(DEFflLA BIAS-CHANGES-TOPOLOGY ITOPO-CHANGE-ACTION-FUN BIAS)) 

(DEFULA BJT-BIAS 

I/:ANTEC (NOT (OEV-TYPE ?Q BJT)) 

</:TO-DO 'TASK (BIAS 'Q ACTIVE) <> 

(/tOO-SUBNET (GENERAL -BIAS-PLAN ?Q) ?TASK <>)»> 

(DEFtlLA BJT-BIAS-NET 

t/iANTEC (NOT (/: PLAN-INSTANCE ?PI (GENERAL -BIAS-PLAN ?Q> ?SUP>) 
(AND (STASK (VBE-FIXER 'Pl> ?SUP <> 

(\ () (FIX '(- (V (BASE ?Q>> (V (EHI ?0))>) ) 
<>) 

(STASK (CB-BIOSER ?PI) ?SUP <> 

<\ (REVERSE-BIAS (CB-JUNCTION ?Q>> ) <>) 

(STASK (IC-FIXER ?PI) ?SUP <> 

(\ () (FIX MI (COL ?Q>)> ) <>) 

(/:HAIN (VBE-FIXER ?PI) ?SOP) 

(/:t1AIN (IC-FIXER ?PI) ?SUP)» 
GENERAL-DP»> 

(OEFHLA TYPICAL-BJT-ONE-STAGE-BIAS 
l-/> A (/: PLAN-INSTANCE 'PI 

(TYPICAL-BJT-ONE-STAGE-BIAS-PLAN ?Q) ?SUP) 
(AND 

(STASK (BVD ?PI) 'SUP <> 

(\ () (ACQUIRE VO) ) <MBVD ?PI)>) 
(STASK (SUPPLY-POUER ?PI) ?SUP <> 

<\ () (ACQUIRE VS) ) <* (POUER-SUPPLY ?PI)>) 
(STASK (RESIS-GETTER ?PI) ?SUP <> 

(\ () (ACQUIRE RESISTOR) ) <' (RE ?PI)>) 
(STASK (BASE-SETTER ?PI) ?SUP <' (BVD ?PI)> 

(\ (VO) (TRMINS-CONNECT (BASE ?Q> (HID ?VD)) ) 
<>) 
(STASK (COLLECTOR-POUER ?PI) ?SUP 
<' (POUER-SUPPLY 'PI)> 
(\ (PS) (DEV-INSERT ?PS (CNOOE ?Q) 
(#2 'PS) 

(NOOE-TERHINALS (CNODE ?Q>) 
(#1 ?PS) <>) ) 
<>) 
(STASK (EMITTER-HUNGER ?PI) ?SUP <' (RE ?PI)> 
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(\ (R> (DEV-INSERT ?R (EHOOE ?Q) 
(#1 ?R> <(EM ?0)> 
(#2 ?R) 
(DEL (EMI ?Q> 

(NODE-TERMINALS (ENOOE ?Q>>>> ) 
<>) 

(REOUCE <(BVO ?PI) (BRSE-SETTER ?PI>> 

(VBE -FIXER ?PI)J 
(REOUCE <(SUPPLY-POUER ?PI) (COLLECTOR-POUER ?PI)> 

(CB-BIRSER ?PI>) 
(REOUCE <(RESIS-GETTER ?PI> (EMITTER-HUNGER ?PI)> 

(IC-FIXER ?Pl>) »> 



(DEFtlLA SPEC-TYPICAL -8JT 

tSPEC-SCHENA (TYPICAL-BJT-ONE-STAGE-BIAS-PLAN ?Q> 
(GENERAL -BIflS-PLRN ?Q)J) 



;COUPLING HAS BEEN SPECIALIZED TO BJT AHPLS. 

(DEFMLA COUPLING-CHANGES-TOPOLOGY tTOPO-CHANGE-ACTION-FUN COUPLE)) 

(DEFMLA COUPLE-DO-1 

t/:TO-00 7TASK (COUPLE 701 'PORT1 7PORT2 702) <> 

</:00-SUBNET (GENERAL -COUPLING-PLAN 701 7PORT1 7PORT2 702) 
7TASK <>)J) 

(DEFMLA COUPLE-NET 

t/tANTEC (NOT (/:PLAN-INSTANCE ?PI 

(GENERAL-COUPLING-PLAN ?01 7PORT1 7PORT2 702) 
7SUP) ) 

(AND (STASK (SIGNAL -MEDIUM-CHOOSE 7PI) 7SUP <> 
(\ (> 

(/:FIND 
(\ (H) 

(ELT 7H <VOLTAGE CURRENT>) )) ) 
<' (MEDIUM ?PI>>) 
(STASK (COUPLE-TYPE -CHOOSE 7PIJ 7SUP <> 
(\ () 
(/iFIND 
(\ (CT) 
(ELT 7CT 

<DIRECT CAPACITIVE 
INDUCTIVE>) )> ) 
<» (COUPLE-TYPE ?PI)>) 
(STASK (CONVERT-PORT-1 7PI) 7SUP <* CREOIUH 7PI)> 
(\ (M) (PORT-CONVERT 7P0RT1 ?H> ) 
<>) 
(STASK (C0NVERT-P0RT-2 7PI) 7SUP <• (MEOIUM 7PI)> 
(\ (M) (PORT-CONVERT 7PORT2 ?fl> ) 
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<>) 

(STRSK (CONNECTOR 7PI) 7SUP <' (COUPLE-TYPE ?P1>> 
(\ (TYPE) 

(PORTS-CONNECT 7PORT1 7PORT2 7TYPE) ) 
<>) 
(/: SUCCESSOR (SIGNAL -HEOIUH-CHOOSE ?PI) 

(CONVERT-PORT-1 7Pl>) 
(/! SUCCESSOR (SIGNRL-HEDIUH-CHOOSE ?PI) 

(C0NVERT-P0RT-2 ?Pl)> 
(/jSUCCESSOR (CONVERT-PORT-1 ?PI> 

(CONNECTOR ?PI)> 
(/SUCCESSOR (CONVERT-PORT-2 ?PI) 

(CONNECTOR ?PI>> 
(/iHAIN (CONNECTOR ?PI) 7SUP) 
)) 



GENERRL-DP*) 



(DEFHLA COUPLE-BEFORE-BIRS 

t-/> fl </:TASK-RCTION 'CT (COUPLE 701 7PRT1 7PRT2 ?02)) 
(-/> G (RNO (COMPONENTS 701 701CS) 
(COMPONENTS ?02 7D2CS) 
(OR (ELT ?Q 7D1CS) (ELT 7Q 7D2CS)) 
(flRIN-DEV-TYPE ?Q BJT)) 
(/iSUCCESSOR ?CT (BIRSER ?Q ?«OOE)))]> 



iSPECIFIC SITUATIONS — 
(OEFULR COUPLE-CE-X-HINTS 

[-/> A (/:TRSK-RCTION 'CT (COUPLE 701 (OUTPORT 701) 7PRT2 702)) 
(-/> G (OEV-TYPE 7D1 CE) 

(/:PKT CE-COUPLE-HINTS (7CT 7D1 7PRT2 702) 
(/: TO-DO 'CT (COUPLE 701 (OUTPORT 701) 
7PRT2 702) <> 
(/: DO-SUBNET 

(CE-OIR-VOL-COUPLE 701 7PRT2 702) 
<>)) 
(/i TO-DO 7CT (COUPLE 701 (OUTPORT 701) 
7PRT2 702) <> 
(/: DO-SUBNET 

(CE-.OIR-CUR-COUPLE 701 7PRT2 702) 
<>)) 
(/sTO-00 ?CT (COUPLE 701 (OUTPORT 701) 
7PRT2 702) <> 
(/iDO-SUBNET 

(CE-CRP-VOL-COUPLE 701 7PRT2 702) 
<>)))))) 



(DEFflLA COUPLE-CC-X-HINTS 

t-/> A (/.-TRSK-RCTION ?CT (COUPLE 701 (OUTPORT 701) 7PRT2 702)) 
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(-/> C (DEV-TYPE ?01 CO 

(/.•PICT CC-COUPLE-HINTS (?CT ?01 ?PRT2 ?D2> 
(/tTO-00 ?CT (COUPLE ?01 (OUTPORT ?01) 
?PRT2 ?02> <> 
(/iDO-SUBNET 

(CC-0IR-V01-C0UPLE ?01 ?PRT2 ?02) 
<>))>>)> 



(DEFflLA CE-DIR-VOL -COUPLE-PLAN 

[-/> (/:PLAN-INSTANCE ?PI 

(CE-DIR-VOL -COUPLE ?D1 ?PRT2 ?02) ?SUP> 
(AND (»/> '(MEOlUrt 'PI) VOLTAGE) 

(=/> ' (COUPLE-TYPE ?P!) OIRECT) 
(/sREOUCEO (SIGNAL-HEOlUn-CHOOSE ?PI>> 
</:REOUCEO (COUPLE-TYPE-CHOOSE ?P!>> 

(STASK (GET-RESISTOR ?PI) ?SUP <> 

(\ () (ACQUIRE RESISTOR) ) <> (RESISTOR ?PI)>) 
(STASK (GET-POWER-SUPPLY ?PI) ?SUP <> 

(\ () (ACQUIRE VOLTAGE-SOURCE) ) <• (VS ?PI)>) 
(STASK (BJT-FINOER ?PI) ?SUP <> 
(\ () 
(/:FINO 
(\ (Q> 

(EXISTS (CS) 

(AND (COHPONEMTS ?01 ?CS) 
(ELT ?Q ?CS) 

(HAIN-DEV-TYPE ?Q BJT>> ))) ) 
<' (TRANSISTOR ?PI)>) 
(STASK (UIRER-1 ?PI) ?SUP 

<• (RESISTOR ?PI) '(TRANSISTOR ?PI)> 
<\ (R Q) (TRfllNS-CONNECT (#2 ?R) (COL ?Q)> ) 
<>) 
(STASK (HIRER-2 ?PI) ?SUP 
<* (RESISTOR ?PI) '(VS ?PI)> 

(\ (R VS) (TRfllNS-CONNECT (#1 ?R) (#2 ?VS>> > 
<>) 

(REDUCE < (GET-RESISTOR ?PI) (UIRER-1 ?PI)> 

(CONVERT-PORT-1 ?PD) 
(-/> A («/> '(TRANSISTOR ?PI) ?Q) 

(-/> A (/.-PLAN-INSTANCE ?BIAS-PI 

(GENERAL -BIAS-PLAN ?Q> ?SUP-BIAS) 
(REDUCE <(GET-POUER-SUPPLY ?PI) 
(UIRER-2 ?PI)> 
(CB-BIASER ?BIAS-PI)))))J) 



(DEFflLA SPEC-CE-OIR-VOL 

ISPEC-SCHEHA (CE-DIR-VOL-COUPLE ?01 ?PRT2 ?02) 

(GENERAL -COUPLING-PLAN ?D1 (OUTPORT ?Ol) 
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7PRT2 ?02) J) 



(DEFtlLA PORT-CONVERT 

!-/> C (AND (I-PORT ?PRT) 

(./> '(PORT-TERMINALS ?PRT) <?TRf1INl ?TRflIN2>) 
(«/> '(NODE-TERMINALS 7TRMN1) ?TS)) 
(/: TO-DO 7TASK (PORT-CONVERT 7PRT CURRENT VOLTAGE) <> 
(CONFIG <RES1STANCE> 
(\ (R) 
<(/:FORK 

(DEV-INSERT ?R 7TRHIN1 

(#1 ?R> 7TS (#2 ?R> <>) 
(\ () 
<(RELABEL-PORT ?PRT I-PORT V-PORT) 
(CONSTRAIN <MI (fl ?R>> (I ?TRMIN1)> 
(\ (IR IT) 

(/>/> (ABS ?!R) 

(ABS 'IT)) ))> ))> ))))) 



(OEFflLA RELABEL 

1/:H0D-I1ANIP 7TSK (RELABEL-PORT ?PRT 70L0 7NEU) 
<* (70L0 ?PRT>> <*(?NEU ?PRT)>)) 



(OEFflLA ACQ-NOOE (NOT (REUSABLE NODE)}) 

(OEFflLA PRIO-NOOE [PRIfHTIVE-OEV-TYPE NODE) GENERAL-OP*> 



(DEFtlLA 2-TERNINHL-DEFN 

l-/> A (DEV-TYPE ?X 2-TERMINAL) 

(/:PKT 2-TERHINAL-PKT (?X> 
(TERMINAL -NAMES 'X <#1 #2>> 
(CONSTRAINT <*(I (#1 ?X)) Ml (#2 ?X))> 

(\ (II 12) (« <+ ?Il 712) 8) )) 
(CONSTRAINT <• (V ?X) '(V (#1 ?X>> * (V (12 7X))> 
(\ (V VI V2) 

(» ?V (- 7V1 7V2)) )))J 
GENERAL-OP*) 



(DEFtlLA PRIH-RESIS IPRIdlTIVE-DEV-TYPE RESISTOR]) 



(DEFtlLA RESISTOR-OEFN 

t-/> A (DEV-TYPE 'X RESISTOR) 
(/iPKT RESISTOR-PKTOX) 

(DEV-TYPE 'X 2-TERflINAL) 
(CONTROL ?X R REALS 1-8) 
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(CONSTRAINT <* <R ?X>> 

(LnnBOfl (R> «/>- » •••» >} 

(CONSTRAINT <MR?X> ■ (V «\™» 

MV (#2 ?X)1 '«l <« W»> 

(lahboa <r vi V2 m 

,, u ?u ?«» <- ? vl 7V2)> >,n 

GENERAL-OP*) 
(0EF1LA BCO-RESISTOR (NOT (REUSABLE RESISTOR.!) 

(0OT PRin-OPEN CPRiniTlVE-OEV-TYPE OPEN!) 

(OEFHLA OPEN-OEFN 

r_/> R (OEV-TYPE 'X OPEN) 

(AND (OEV-TYPE ?X 2-TER.1INAL) 

(CONSTRAINT <• (I (*1 ?X))> 

(LAHBDA (I) (- « B) " 
(CONSTRAINT <' (I (f2?X))> 

(LAHBOA (I) <- « 8) "" 

GENERAL -OP*) 

, 0E rm. B p..«- S ™ B t .MiniT.vE-Kv-TYPE S ho.t.. 

mrM «««_„, „ ,„„„, 

GENERAL-OP*) 

cnPPMLA WIIMW tPRinniVE-DEV-TYPE CAPACITOR)) 
SlA Rci-CBP tNOT (REUSABLE CAPACITOR))) 

« 0EF „ L A C^H oEvTYpE ?x cnpflcnoR) 

(/tPKT CAP-PKT (?X) 

(OEV-TYPE ?X 2-TERHINAL) 
(CONTROL ?X C REALS 1.21 
(CONSTRAINT <MC ?X)> 

(LAMBDA (C) (/>- « «•«> » 
(N (DC) ' (OEV-TYPE ?X CAPACITOR). 
(T (OC) (OEV-TYPE ?X OPEN)) 
N (SSS'S) • (OEV-TYPE ?X CAPACITOR)) 
T SSS >S) <«HO (OEV-TYPE ?X RESISTOR) 
(./>MR?X) 

(// 1.1 (* <C ?X) ?S))))> 



GENERAL -OP*) 



<H (HIGH-FREQ) (OEV-TYPE ?X CAPACITOR.) 
(T (H1GH-FREO. (OEV-TYPE 7> SHORT...1 
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<oefhla priii-imduc [primitive -dev-type inductor)) 



<DEFM.fi INOUC-OEFN 

t-/> R (OEV-TYPE 'X INDUCTOR) 
(/:PKT INDUC-PKT <>X> 

(DEV-TYPE ?X 2-TERriINRL) 
(CONTROL ?X L REALS 1.5) 
(CONSTRAINT <• (L ?X)> 

(LAMBDA (L) </>« ?C 6.8) 
(N (DC) '(DEV-TYPE ?X INDUCTOR)) 
(T (DC) (OEV-TYPE ?X SHORT)) 
(N (SSS ?S> '(DEV-TYPE ?X INDUCTOR)) 
(T (SSS ?S) (AND (OEV-TYPE ?X RESISTOR) 
(=/> ' (R ?X) 

(* (L ?X) ?S)>)) 
(N (HIGH-FREQ) (DEV-TYPE ?X INDUCTOR)) 
(T (HIGH-FREQ) (DEV-TYPE ?X SHORT)))] 
GENERAL-DP*) 



)) 



(DEFHLA COMP-XFMR ICOMPOSITE-DEV-TYPE TRANSFORMER) > 



(DEFHLA XFHR-OEFN 

!-/> A (DEV-TYPE ?X TRANSFORMER) 
(/:PKT XFHR-PKT (?X) 

(TERMINAL-NAMES ?X <fl.l *L2 *R1 *R2>> 
(CONTROL ?X TURNS-RATIO REALS 1) 
(CONSTRAINT <• (TURNS-RATIO ?X>> 

(\ (N> (/> ?N 8) )> 
(CONSTRAINT <MI (#L1 ?X)) '(I (*L2 ?X)>> 

(\ (U 12) (« (♦ ?I1 ?I2) 8) 
(CONSTRAINT <MI (*R1 ?X)> '(I (*R2 ?X))> 

(\ (13 H) <=. <+ ?I3 ?U) 8) 
(CONSTRAINT <• (V (111 ?X>> '(V (IL2 ?X)) 
'(V (#R1 ?X>) MV (#R2 ?X)> 
MI (111 ?X>) '(I (#R1 ?X))> 
(\ (VL1 VL2 VR1 VR2 IL IR) 
(= (.+ (♦ (- ?VL1 ?VL2) ?IL) 
(* (- ?VR1 ?VR2) ?IR)) 
8) )))I) 



)) 



)) 



I H TRANSFORMER HAY CONSIST OF TUO INDUCTORS 

<DEFm.fi OERIVED-XFMR 

t/! TO-DO 'TASK (HAKE TRANSFORMER) <?NAHE> 

(/iOO-SUBNET (BUM-TWO-INDUCTORS) <XFMR>>] 
GENERAL-DP*) 



(DEFMLfl BUM- INDUCTORS-NET 

t-/> A (/: PLAN-INSTANCE 'PI (BUM-TWO-INDUCTORS) ?SUP> 
(ANO (STASK (GET^INDUC-1 ?PI) ?SUP <> 
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(\ () (ACQUIRE INOUCTOR)) <• (LI ?PI)>) 
(STASK (GET-INDUC-2 'PI) ?SUP <> 

(\ () (ACQUIRE INDUCTOR)) <• (L2 ?PI)>) 
(STflSK (HBRfl ?P1> ?SUP <»(Ll ?PI) * (L2 ?PI>> 
(\ (LI L2) (GRRBBB 
(\ (X) 

(tlAIN-DEV-TYPE ?X TRANSFORMER) 
<• (XFMR ?PI)>) 
(STflSK (CADP.BR A ?PI) ?SUP 

<'(L1 ?PI) '(L2 ?PI) MXFMR ?PI)> 
(\ (LI L2 XFMR) 

(/: INFER '(COMPONENTS ?NAHE <7L1 ?L2>) 
<>) ) 
<>) 
(/(MAIN (flBRA ?PI) ?SUP))1 



))> 



GENERO.L-DP*) 



(DEFULfl IOEflL-VS tlOEAL-DEV-TYPE VOLTAGE-SOURCE1 ) 

(OEFtlLA REUSABLE -VS (REUSABLE VOLTAGE-SOURCE!) 

(OEFttLfl VS-DEFN 

(-/> fl (DEV-TYPE ?X VOLTAGE-SOURCE) 
(AND (DEV-TYPE ?X 2-TERMINAL) 
(CONTROL V ?X REALS 1) 

(CONSTRAINT <' (V ?X> • (V (#1 ?X)) '(V (#2 ?X)>> 
(\ (V VI V2> (. ?V (- ?V1 ?V2)) )))J) 

(DEFtlLA PRII1-BJT (PRIMITIVE-OEV-TYPE BJTJ) 

(DEFMLA BJT-DEFN 

t-/> fl (DEV-TYPE 'Q BJT) 

(/:PKT BJT-PKT (?Q) 

(TERMINAL -NAMES ?Q <BASE EMI COL>) 
(CONTROL POLARITY >Q <*1 -1> 1) ;NPN VS PNP 
(CONTROL BETA ?Q (INTERVAL It 5M> 19.) 
;BETA CONTROLLABLE UP TO ORDER OF MAGNITUDE 
(CONTROL RPI ?Q REALS 1.5) 
> INCREMENTAL BASE RESISTANCE 

(-/> A (HOOE ?Q 'fl) 

(STASK (BIASER ?Q ?H) (OEEP-FREEZE ?M> <> 
<\ () (BIAS ?Q ?M> ) <>)) 



(-/> fl (HOOE ?Q ACTIVE) 
(AND 

(CONSTRAINT <• (I (BASE ?Q)> 

'(I (COL ?0>) '(BETA ?Q)> 
(LAMBDA (IB IC BETA) 

<» ?IC (* 'BETA ?IB)) )) 
(CONSTRAINT <• (I (COL ?Q)> » (I (Eftl ?Q))> 
(LAMBDA (IC IE) 
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<« <♦ ?ic ?ie> e.e> >) 

(CONSTRAINT <MI (BASE ?Q))> ZEROP) 
(CONSTRAINT <• (V (BASE ?Q)) '(V (EM ?Q>) 
' (POLARITY ?Q)> 
(LAtlBDA (VB VE S) 

<- (- ?VB ?VE) (* 8.6 ?S>) >> 
(INEQ (V (BASE ?Q)> (V (EM ?Q>> 

(POLARITY ?Q)> 
(INEQ (V (COL ?Q)) (V (BASE ?Q>> 

(POLARITY ?Q>> 
(INEQ (I (COL ?Q)> 8 (POLARITY ?Q>> 
(INEQ (I (BASE ?Q>> 8 (POLARITY ?Q)) 
(INEQ 8 (I (EM ?Q>> (POLARITY ?0>))) 

(-/> A (HOOE ?Q CUTOFF) 
(AND 

(CONSTRAINT <» (I (COL ?Q)>> ZEROP) 
(CONSTRAINT <'(I (BASE ?Q))> ZEROP) 
(CONSTRAINT <'(I (EM ?Q))> ZEROP))) 

(-/> A (RODE 'Q SATURATED) 

(CONSTRAINT <• (V (COL ?Q>> '(V (EM ?Q)) 
'(POLARITY ?Q)> 
(LAtJBOA (VC VE S) 

(. ?VC (♦ ?VE (// (» 8.6 ?S> 2.8))) ))) 

(N (INC) '(CONSTRAINT <• (V (BASE ?Q)) '(V (EM ?Q>) 
'(POLARITY ?Q)> 
(LAflBOA (VB VE S) 

(» (- ?VB ?VE) (* 8.6 ?S>) ))) 
(T (INC) (CONSTRAINT <• (V (BASE ?Q)> '(V (EM ?Q)> 
'(I (BASE ?Q)> MRP I ?Q> > 
(\ (VB VE IB R) 

<» (- ?VB ?VE) (* ?IB ?R)) ))) 



)J 



GENERAL-DP*) 

(DEFHLA INEQ-1 

!-/> A (INEQ ?X ?Y ?S) 

(AND (-/> C (/> ?S 8) (/> ?X ?Y>) 

(-/> C (/< ?S 8) (/< ?X ?Y)))I) 

(COtlPOSITE DEVICES 

(DEFtlLfl SIG-TRANSER-GLORIA-HUNDI 

[-/> A (DEV-TYPE 'X SIG-TRANSER) 

(PORTS ?X <(INP0RT 'X) (OUTPORT ?X)>) ]) 



(DEFHLA NOOES-DECL-DEFN 

[-/> A (NODES ?OEV ?NODE-TUP) 

(-/> G (ELT ?N ?NOOE-TUP) (HAIN-DEV-TYPE ?N NODE)) J 
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GENERAL -0P*> 



(OEFMLfl PORTS-DECL-OEFN 

{-/> A (PORTS ?0EV 7PORT-TUP) 

(-/> G (ELT ?PRT 7PORT-TUP) (MAIN-OEV-TYPE ?PRT PORT))J) 

(DEFMLA AMP-SIG-TRRNS [SUB-DEV-TYPE AMPLIFIER SJG-TRRNSER1) 



(DEFflLA CE -BASIC IBASIC-DEV-TYPE CE1) 

(DEFflLA CE-ArtP tSUB-OEV-TYPE CE AMPLIFIERl) 

(DEFflLA flOST-GEN-CE IMOST-GENERAL-SPEC CE GENERRL-CE) ) 

(DEFflLA CE-OEFN 

t-/> A (OEV-TYPE ?CE GENERRL-CE) 
(ZtPKT CE-PKT (?CE) 

(COMPONENTS ?CE <(Q ?CE)>> 

(NOOES ?CE <(BNOOE ?CE) (ENOOE ?CE) (CNOOE >CE>>) 

(OEV-TYPE (Q ?CE> BJT) 
(MODE (Q 'CE) ACTIVE) 

(/sSUBTASK (BIASER (Q ?CE) ACTIVE) (0EEP-FREE2E ?CE>) 
(/:TO-00 (BIASER (Q ?CE) ACTIVE) ?fl <> 
(/: DO-SUBNET 

(TYPICAL-BJT-ONE -STAGE-BIAS (Q ?CE)> <>)) 



(-/> '(NODE-TERMINALS (BNOOE ?CE)> <(BASE (Q ?CE))>) 
(«/> ' (NOOE-TERfllNALS (ENODE ?CE>> <(EHl (Q ?CE))>) 
(»/> '(NODE-TERMINALS (CNOOE ?CE>) <(COL (Q ?«)>>> 

(I-PORT (INPORT ?CE>) 
(PORT-TERMINALS (INPORT ?CE) 

< (BNOOE ?CE) (ENOOE ?CE)>) 
(I-PORT (OUTPORT ?CE)) 
(PORT-TERMINALS (OUTPORT ?CE) 

< (CNOOE ?CE) (ENOOE ?CE)>) 
)) 
GENERAL-DP*) 



(DEFflLA DEFAULT-CE IDEFAULT-SPEC CE TYPICAL-CEI) 

(DEFflLA DERIVATION-TYP-CE tOERIVEO TYPICAL -CE GENERAL -CE1) 

(DEFflLA TYPICAL -CE-OEFN 

1/tHNTEC (NOT (OEV-TYPE 7TYP-CE TYPICRL-CE)) 
(/:PKT TYPICAL -CE-PKT (7TYP-CE) 
(DEV-TYPE 'TYP-CE CE) 
(COMPONENTS 7TYP-CE <(Q ?TYP-CE) (Rl 7TYP-CE) 
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jFROZEN TASKS 



(R2 7TYP-CE) (RE 7TYP-CE) 
<RL ?TYP-CE)>) 

MAIN-DEV-TYPE (Q 7TYP-CE) BJT) 
((10DE (Q 7TYP-CE) ACTIVE) 
(IWIN-DEV-TYPE (Rl 7TYP-CE) RESISTOR) 
(tlAlN-DEV-TYPE (R2 7TYP-CE) RESISTOR) 
(HAIN-DEV-TYPE (RE 7TYP-CE) RESISTOR* 
(HAIN-OEV-TYPE (RL ?TYP-CE) RESISTOR) 

(NOOES ?TYP-CE <(BNOOE 7TYP-CE) (CNOOE 7TYP-CE) 
(ENOOE 7TYP-CE) (GMO 7TYP-CE) 
(PNOOE ?TYP-CE)>) 

(./> ' (NODE-TERM NALS (BNOOE 7TYP-CE)) 
<<BASE (Q >TYP-CE)> (#2 (Rl 7TYP-CE)) 
(#1 (R2 ?TYP-CE))>) 
(-/> • (NODE-TERMNALS (ENOOE 7TYP-CE)) 

<(EM (Q ?TYP-CE>> (#1 (RE ?TYP-CE))>) 
(-/> ' (NOOE-TERMNALS (CNOOE 7TYP-CE)) 

<(COL (Q 7TYP-CE)) (J? (RL 7TYP-CE))>> 
(-/> '( NOOE -TERM NHL S (PNOOE 7TYP-CE)) 

<(#1 (Rl ?TYP-CE>) (#1 (RL 7TYP-CE)>>> 
(»/> '(WOE-TERMINALS (CND 'TYP-CE)) 

<(#2 (R2 7TYP-CE)) (#2 (RE ?TYP-CE))>) 



</:PLAN-INSTANCE (FROZEN-BIAS-PLAN 7TYP-CE) 
(TYPICAL-BJT-ONE-STAGE-BIAS (Q 7TYP-CE)) 
(BIASER (Q ?TYP-CE) ACTIVE)) 

(/:REOUCED (BIASER (Q 7TYP-CE) ACTIVE)) 

(FUNCTION (Rl ?TYP-CE) (BVO (FROZEN-BIAS-PLAN 7TYP-CE))) 
(FUNCTION (R2 7TYP-CE) (BVO (FROZEN-BIAS-PLAN 7TYP-CE))) 
(FUNCTION (RE 7TYP-CE) 

(RESIS-GETTER (FROZEN-BIAS-PLAN ?TYP-CE>>> 



(STRSK (PORT-CVT 7TYP-CE) (DEEP-FREEZE 7TYP-CE) <> 
(\ () (CONVERT-PORT (OUTPORT 7TYP-CE) 

CURRENT VOLTAGE) ) 
<>) 

(FUNCTION (RL 'TYP-CE) (PORT-CVT 7TYP-CE)) 

(EXPANSION-OBL 7TYP-CE (FIX '(V (PNOOE 7TYP-CE)))) 

(/sSUBTASK (OBL 'TYP-CE (FIX ' (V (PNOOE 7TYP-CE)))) 

(BIASER (Q 7TYP-CE) ACTIVE)) 

(CONSTRAINT <• (POLARITY (Q 7TYP-CE)) 

•(SIGN (V (PNOOE ?TYP-CE)))> 
= ) 
(CONTROL V-GAIN 7TYP-CE (INTERVAL -5B 58) 2) 
(CONSTRAINT <• (V-GHIN 7TYP-CE) ' (R (RL 7TYP-CE)) 



Appendix 3 247 



'(R (RE ?TYP-CE>>> 
(LRflBOA (AV RL RE) (. ?AV (// ?RL ?RE>> 



)) 



)] 



GENERAL -OP*> 



(DEFHLfl BRSIC-VO tBRSIC-DEV-TYPE VDI) 

(DEFULR VD-DEFN 

t-/> R (OEV-TYPE ?VO VD> 
(/iPKT VO-PKT (?V0) 

(COMPONENTS ?VD <(R1 ?VO) <R2 ?VO)>) 
(NODES ?VD <(TOP ?VO) (MD ?VD) (BOT ?VO)>) 

(nniN-OEV-TYPE (Rl ?VO) RESISTOR) 
(flRIN-OEV-TYPE (R2 ?VO) RESISTOR) 

(*/> ' (NODE-TERniNRLS (TOP ?VD)> <(#1 (Rl ?VO))>) 
(•/> * (NODE-TERMINALS (MO ?VD>> 

<(#2 (Rl ?VD)) (#1 (R2 ?VO))>) 
(•/> MNOOE-TERtllNRLS (BOT ?VO>) 

<(#2 (R2 ?VO))>) 

(OEV-TERtllNRLS ?VO 

<(TOP ?VO) (MO ?VO) (BOT ?VO)>) 



I FROZEN TASKS 



(EXPRNSION-OBL ?VO (FIX '(V (TOP ?VD>>>) 
(EXPRNSION-OBL ?VD (FIX '(V (BOT ?VO)))) 

(CONSTRAINT <• (V (TOP ?VD>> '(V (BOT ?VO») 
'(V (MD ?VO)) 

'(R (Rl ?VTJ)) »(R (R2 ?VTJ))> 
(\ (VI V2 V Rl R2) 

(* ?V (// <+ (* ?R2 ?V1) <* ?Rl ?V2)) 
(♦ ?R1 ?R2>>) )) 

(CONSTRAINT <'(I (niO-NODE ?VTJ)) 

•(I (#2 (Rl ?VO)))> 

(\ (I ID (/</< (RBS ?I) (RBS ?ID) )) 

(CONSTRAINT <*(I (MO-NODE ?VD>> 

MI (#1 (R2 ?VO)))> 

(\ (I 12) (/</< (ABS ?I> (RBS ?I2)) )) 



)] 



GENERAL -DP*) 



(DEFMLA RCO-VD INOT (REUSABLE VOID 
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»flS WITH CE, THERE IS AN ABSTRACT ECP UHICH IS A CURRENT AMPLIFIER 

(DEFMLA BASIC-ECP (BASIC-DEV-TYPE ECP) > 

(DEFflLA ECP-IS-RHP ISUB-OEV-TYPE ECP AMPLIFIER)) 

(DEFMLA HOST-GENERAL-ECP IMOST-GENERAL-SPEC ECP CEMERAL-ECP) ) 

(DEFMLA ECP-DEFM 

t-/> A (OEV-TYPE ?ECP GENERAL-ECP) 
(/:PKT ECP-PKT (?ECP) 

(COMPONENTS 'ECP <(Q1 ? E CP) (Q2 ?ECP)>) 
(NODES ?ECP < (ENOOE 'ECP) 

(BNOOE1 ?ECP> (BN00E2 ?ECP) 
(CNOOE1 ?ECP) (CNODE2 ?ECP>>> 

(MAIN-OEV-TYPE (Ql ?ECP) BJT) 
(MODE (QI ?ECP> ACTIVE) 
<MAIN-OEV-TYPE (Q2 ?ECP) BJT) 
(MODE (Q2 ?ECP) ACTIVE) 

(»/> '(NODE-TERMINALS (ENOOE ?ECP>) 

<(EMI (Ql 'ECP)) (EMI (Q2 ?ECP>)>> 
(»/> * (NODE-TERMINALS (BN00E1 ?ECP>> 

<(BASE (Ql ?ECP>)>) 
(•/> '(NODE-TERMINALS (BN0DE2 ?ECP)> 

<(BASE (Q2 'ECP>>>> 
(»/> '(NODE-TERMINALS (CN00E1 ?ECP)) 

<(COL (Ql 'ECP>>>) 
(=/> "(NODE-TERMINALS (CN00E2 ?ECP)) 

<(COL (02 ?ECP))>) 



(PORTS ?ECP <0UTP0RT-1 0UTP0RT-2>) 

(V-PORT (INPORT ?ECP)) 
(PORT-TERMINALS (INPORT ?ECP) 

<(BN0DE1 'ECP) (BN00E2 ?ECP)>) 

(I-PORT (OUTPORT-1 ?ECP)> 
(PORT-TERMINALS (OUTPORT-1 ?ECP) 

<(CN0DE1 'ECP) (ENOOE ?ECP)>) 
(I-PORT (0UTP0RT-2 ?ECP)) 
(PORT-TERMINALS (OUTPORT-2 ?ECP) 

<(CN0DE2 ?ECP) (ENOOE ?ECP)>> 

(/sSUBTASK (BIA5ER (Ql ?ECP) ACTIVE) 

(DEEP-FREEZE ?ECP>> 
(ASUBTASK (BIASER (Q2 ?ECP) ACTIVE) 

(DEEP-FREEZE ?ECP>) 
(EXPANSION-OBL 'ECP (FIX MI (ENOOE ?ECP)))))J) 



(DEFMLA OEFAULT-ECP IOEFAULT-SPEC ECP ECP-DC-AHPJ) 
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(OEFULA DERIVE0-ECP-0C-AI1P tOERIVEO ECP-DC-AUP ECPJ) 

(DEFflLA ECP-OC-ArtP-DEFN 

1/iANTEC (NOT (OEV-TYPE ?TYP-ECP ECP-OC-AtIP) > 
(/:PKT ECP-OC-AHP-PKT <?TYP-ECP> 
(COMPONENTS 7TYP-ECP 

<(D1 7TYP-ECP) (Q2 7TYP-ECP) 
(RL ?TYP-ECP) (RE ?TYP-ECP)>) 
(DEV-TYPE (RL 7TYP-ECP) RESISTOR) 
(OEV-TYPE (RE ?TYP-ECP) RESISTOR) 
(OEV-TYPE (01 nYP-ECP) BJT) 
(OEV-TYPE (02 ?TYP-ECP) BJT) 
(HOOE (Ql 7TYP-ECP) ACTIVE) 
(HOOE (02 7TYP-ECP) ACTIVE) 

(NODES 7TYP-ECP 
<(ENOOE HYP^ECP) (LOHNOOE ?TYP-ECP) 
(HIGHNOOE 'TYP-ECP) 
(C2N00E ?TYP-ECP) (B1N00E 7TYP-ECP) 
(B2N0DE ?TYP-ECP)>) 
(»/> ' (NOOE-TERtllNHLS (ENOOE ?TYP-ECP)) 
<(EM (01 ?TYP-ECP)) (EM (02 ?TYP-ECP)> 
(#1 (RE ?TYP-ECP))>) 
(=/> ' (NOOE-TERMNALS (LOUNOOE ?TYP-ECP)) 

<(#2 (RE ?TYP-ECP))>) 
(»/> » (NOOE-TERMNALS (HIGHNOOE 7TYP-ECP)) 
<(COL (Ql ?TYP-ECP)> (#1 (RL ?TYP-ECP)>>) 
(«/> ' (NOOE-TERMINALS (C2N00E 7TYP-ECP)) 

<(COL (02 ?TYP-ECP)) (#2 (RL ?TYP-ECP>)>> 
(./> '(NOOE-TERMINRLS (81N00E 7TYP-ECP)) 

<(BRSE (01 ?TYP-ECP>>>> 
(»/> '(NOOE-TERtllNRLS (B2N00E 7TYP-ECP)) 
<(BRSE (Q2 ?TYP-ECP))>) 

» THESE ARE UAYS OF DOING TASKS IN ABSTRACT ECP... 
(EXPANSION-OBL 7TYP-ECP 

(FIX '(V (LOUNOOE 7TYP-ECP)))) 
(EXPANSION-OBL 7TYP-ECP 

(FIX MV (HIGHNOOE 7TYP-ECP)))) 

(REOUCE <(OBL 7TYP-ECP 

(FIX '(V (LOUNOOE 7TYP-ECP))))> 
(OBL (SOUL 7TYP-ECP) 

(FIX »<I (ENODE (SOUL 7TYP-ECP) ) > > ) > 

(REDUCE <(OBL 7TYP-ECP 

(FIX MV (HIGHNOOE 7TYP-ECP))))> 
(BIRSER (Ql (SOUL 7TYP-ECP)) ACTIVE)) 
(REOUCE <(OBL 7TYP-ECP 

(FIX '(V (HIGHNOOE ?TYP-ECP))))> 
(BIRSER (02 (SOUL 7TYP-ECP)) ACTIVE) > 



(STASK (CVT-PORT 7ECP) (DEEP-FREEZE 7TYP-ECP) 
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<> (\ () (PORT-CONVERT (OUTPORT 7TYP-ECP) 
CURRENT VOLTAGE) ) <>) 
(FUNCTION (RL 'TYP-ECP) (CVT-PORT ?ECP>) 

(FUNCTION (RE 7TYP-ECP) 

(OBL (SOUL 7TYP-ECP) 

(FIX MI (ENOOE ?ECP>)>)> 

(CONSTRAINT <MI (RE ?TYP-ECP>>> 

(\ (I) (. ?I 8.082) )) 

(CONSTRAINT <' (I (COL (Ql ?TYP-ECP)>> 
'(I (COL (Q2 ?TYP-ECP)))> 
«))]) 



(OEFHLA RC-OEV-TYPE 

(-/> fl (OEV-TYPE 'RC RC-FILTER) 
(/«PKT RC-PKT <?RC> 

(OEV-TYPE 'RC SIC-TRANSER) 
(COMPONENTS ?RC <(R1 >RC) (CI 'RC>>) 
(NODES ?RC <(NOOEl >RC1 (N00E2 ?RC> (NOOE3 ?RC)>) 
(./> ' (NODE-TERIIINALS (NOOE1 >RO) <(#1 (Rl ?RC)>>> 
(«/> MNOOE-TERrtlNALS (N00E2 ?RC>) 
<(#2 (Rl 'RO) (#1 (CI ?RC))>) 
(»/> ' (NOOE-TERHINALS (N00E3 ?RC>) <(#2 (CI ?RC>>>> 

(V-PORT (INPORT ?RO) 

(PORT-TERniNALS (INPORT ?RC) <(NODEl ?RC) (N00E3 ?RC)>> 

(V-PORT (OUTPORT ?RC>> 

(PORT-TERMNALS (OUTPORT ?RC) <(NO0E2 ?RC) (N00E3 ?RC)>) 

(CONTROL CUTOFF-FREQ ?RC POS-REALS 1) 
(CONTROL (H ?S> ?RC COI1PLEX 1.2) 

(CONSTRAINT <• (CUTOFF-FREQ ?RC) 

*(R (Rl ?RC)> '(C (CI ?RC))> 
(\ (F R C) (» ?F (// 1 (« ?R ?C>>> )) 



(CONSTRAINT <M(H ?S) ?RC) MR (Rl ?RO) MC (CI ?RC))> 

(\ (H R C> (« ?H (// 1 (+ 1 (* ?R ?C ?SJ>)> )) 
)1) 
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Appendix 4 — Details of STP ror Theorem Provers 

The main requirement for an information-retrieval theorem prover is that 
it halt. This is hard because it must return as many answers as possible. If 
the theorem prover were the top level, as is usually the case, we could just 
let it run until we ran out of money or patience, but the problem solver above 
it needs its answers in a finite time. STP has been written with this 
emphasis in mind; in its design, I have sacrificed "completeness" to this 
"finiteness" requirement. 

STP is organized as a backward-chaining PLANNER- 1 ike system. (Moore, 1975) 
Given a goal, it finds implications to back through. For example, with the 
goal "Refute [NOT (P ?XH," it might back through (-/> C (AND (0. ?X) (R ?X)) 
(P ?X)1, which is internally stored as the disjunction [/:C0NSEQ (P ?X) (NOT 
(AND (Q ?X) (R ?X)))]). The reason implications are internally disjunctions 
is that STP wants to retrieve /:ANTECs in the same fetch as /:C0NSEQs. so it 
must put the index pattern in the same place. It is for this reason that 
atomic data are stored as (/rCONSEQ |pat| FALSE!. 

This backward chaining creates a conjunction of subgoals, each of which is 
treated similarly to the way the top-level one was. The other subgoals are 
held in abeyance while the chosen one is worked on. This is called 
"splitting" for reasons I wi I I explain below. The chosen subgoal can sprout 
new subgoals, so the conjunction grows. 

Uhen a subgoal is reduced to FALSE, the resulting answer substitution is 
applied to the remaining conjuncts before they are split. Uhen there aren't 
any more, the substitution is the final result. I wi I I say more about "answer 
substitutions" below. 

Backtracking is necessary because there may be more than one split, and 
because there may be more than one answer to try on remaining conjuncts. 
Backtracking is implemented by saving the theorem-prover state when such a 
choice arises; and restoring such states when branches run out of choices, and 
after each top-level answer has been found. 

To limit backtracking, failures are not af lowed to cause backtracking to 
an irrelevant choice point. Splits, when generated or augmented, are 
partitioned into "split groups," each member of which is a conjunction which 
shares no free variables with the others. (Ernst, 1973, Moore, 1975) For 
example, if (-/> C (AND (P ?x) (Q ?y)) (R ?x ?y)J, the goal (NOT (R ?u ?v)J 
gives rise to two independent subgoals (NOT (P ?u)J and (NOT (Q ?v)]. All the 
answers are found to each, and the result is the "Cartesian product" of the 
answer sets of each. That is, if (P a! and [P b] , and [Q cl and (Q d! are 
present, [R a cl , (R a d! , [R b cl , and (R b d! are deducible. 

A request to STP uith free variables is interpreted as a demand for values 
of those variables which refute the request. In the example I just gave, the 
request (NOT (R ?u ?v)] is satisfied by four such sets. These are called 
answer substitutions. They are computed from the history of the matches from 
the original request to the instances of (FALSE! that are ultimately derived. 
For example, given the request (NOT (P ?x ?y)l and the axioms (/:C0NSFQ (P ?u 
B) (NOT (Q ?u))] and (/:C0NSEQ (NOT (Q A)) FALSE], the first backward chain to 
(NOT (Q ?x)] constrains ?y to be (B! ; the chain to (FALSE! then sets ?x to 
(A! . 

This bookkeeping is handled in STP by use of the Boyer-Moore 
representation of clauses. (Boyer and Moore, 1972) The idea is to represent 
every clause as a pattern plus substitution. The substitution is called an 
environment. A formula represented this way is called a closure. Matching 
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tuo closures creates a new. more constrained environment which describes the 
new substitution as a further specification of the two old ones. In this way, 
each environment really specifies a binary tree of super-environments which 
parallel its deductive history. Boyer and Moore explain how a numerical 
"environment id" or envid can specify any branch of this tree. Giving two 
envids specifies the node where the two branches meet. 

STP uses this device to keep track of answers to goals. The variable ANS- 
ENVID* specifies the envid of the current main goal. The variable. MAIN-MAX* 
specifies the size of the tree above the main goal's environment; that is, 
ANS-ENVID* and ANS-ENV1D* + MAIN-MAX* are two envids which uniquely specify 
the environment of the main goal. The function ENV-COLLAPSE takes the 
environment of a terminal [FALSE] and these tuo numbers and produces an 
environment with all the discovered constraints recorded. This mechanism 
makes unnecessary the "answer -predicate" construct of (Green, 1969).. 

Of course, this mechanism is more specialized than Green's, since it is 
not able to return "disjunctive" substitutions. Thus, it will not uork if the 
request [NOT (P ?X)1 appears with [/:C0NSEQ (P A) (P B)J, even though these 
formulas are provably inconsistent. (The IP B] detached by the first 
resolution matches the original goal.) It won't work because there is no 
assignment of one value to X which refutes [NOT (P ?X)]. This is not really a 
deficiency in doing information retrieval, but we must be careful to detect 
it. I uill say how this is done after a short digression. 

STP is a refutation-driven theorem prover. This means that it doesn't 
just back through implications, it also records the formulas it is trying to 
refute so that they can take part in deductions. Uhen the prover returns, all 
of these effects must disappear. This is accomplished by "pushing" the 
current data pool, doing recording formulas in it, and "popping" at the end. 
(McDermott and Sussman, 1973) This is done for every subgoal as well. 

Now the machinery can allow several kinds of interactions between goals. 
The kind I mentioned two paragraphs ago is called "befuddlement . " This is when 
two matching subgoals specify conflicting substitutions. This is handled by a 
program (TP-STATUS-RECONCILE) , which forces agreement between two conflicting 
lines of deduction; it insists that just one ANS-ENVID* be passed along. 

Another kind of interaction is subsumpt ion. If a new goal is subsumed by 
a fact not in the pushed data pool, it is abandoned. For example, even if 
there are axioms for proving [P ?X1 , there is no point in trying to prove (P 
Al (that is, refute (NOT (PA)]), if [NOT (P A)] is in the data base. If you 
succeeded in deriving such a proof, it would be of little value, since it 
would just prove the inconsistency of the data base with regard to this 
question. 

More interesting is the case where the subsumer is another goal. This 
case must be noticed, since the subsumer may be a super-goal of the current 
one, and therefore an infinite recursion may be impending. In any case, there 
is usually no point in proceeding, so STP abandons this goal. (This puts the 
program even further from deductive completeness.) However, there is an 
important case in which mere abandonment is not enough. If the super-goal is 
a main super-goal which is a variant of the current one, the answers to the 
9uper-goal must be applied to this one. For example, given the axioms 

[/:C0NSEQ (ABOVE ?X ?Y) (NOT (ON ?X ?Y))] 
[/rCONSEQ (ABOVE ?X ?Z) 

(NOT (AND (ABOVE ?X ?Y) (ON ?Y ?Z))H 
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sSbgol? °NOT \llnw\ t ,yu e T S l RefUte tN ° T (AB0VE A ?V,] " wi ' ' Cf ~eate a 
recurs on i I ,^Z > V\ " h ' Ch ' S 9Ub8umed b W it. The resulting infinite 
soluHnn il% POrt f t0 3 P ' ain the0rem P rover « but important to us. The 

answers LlAVTTV * he 3 ^^b\ and subgoal in such a way that all 

answers TuL ?, V^\'° thB SUPer9 ° al are translated into subgoal 
answers. Thus, if the data base contains tON A B] , tON B CJ , and [ON r PJ 

noti^erand^hi f 'V"" 8 ' ^f' 6 V * tB] ' ^ -peated'subgoa' ui • - be 
"NOT mN RW1 UK .K n3Wer M,M be USed ' caU9in 9 the detachment of subgoal 
INUT (ON B ?V)] Uhen this succeeds, the answer V ^ [CI will have been found 

detach nVtNo7(ON C**V,° T^" "" rWted 9Ubg0a ' ^ tMsTme V 

prod a uces 9 no N ne H 'answers! 1 ^ ^ ^^ V * TO ' The fina ' ««" ™ D ™ 

of answers'Io^uhl^^r I," 56 ™P Mt »" 9Ub g°^ depends on the calculation 
or answers to subgoals as well as the main theorem-prover goal. This is 
surp r , 9mgl dlff icu.t to accomp.ish in conjunct ion wi th th p, i -group 

' b " a i; S :' B ? C K USe 9 ° a,S ^ be r60r dered ' jt ' 9 not obvious hen the 
stack of ?ti In ?° h3 rV 5een finished - Every goal structure must .fore a 
for «nh I ancest °rs. The program ANSWERS -RECORD checks this stack to ,n P 
for each ancestor, whether there are any outstanding sibling goals If not" 
an answer for that ancestor may be recorded. 

in the'data°b^p 9 °?h° ne 5PMt °' * g ° a '* STP d ° eS not record competing splits 
bC R Moore ! S, I ' ^V the J ™ devi ° U9 kind9 of reasoning discussed 
trouble n0t n0t,Ced ' ThiS C0U,d be chan 9 ed wit h°"t too much 



Other features: 



Equality -- STP uses equalities of the form [-/> '|x| lul] routine I u murh 

subLpressIonsthicrL" 6 ^ a B ^-"°°re closure, and attempts to evaluate 

u b f? CHanged by the neM environment. Evaluation is 

caM s Lll »h request to refute [./> '|neu pat] ?VAU . Before thi» 

♦hi I V M 6 var,ables in the Pattern are "marked universal," meaning 

oe eou v'a^nt 3 Xl ma° V ^ "" ^ matChing ^ bg STP? this* turnout to 
hL! 1 ?u the "lark.ng done in packets. (McDermott, 1975) If it ..ere not 

done more than one "value" could be derived for the new pattern. 

given h ;he e ::!om a s ,0n " *"" ^^ * »"™ ' S detached ' ^ example, 



-/> (F (G A)) B] [./> «(F (G CM D] 

t/:C0NSEQ (P (G ?X) ?Y) (NOT (Q ?X ?Y))J 

t/:CONSEQ (Q A ?Y) (NOT (R ?Y))J 
tR B] 



and the request, "Refute [NOT (P ?ll (F ?iun « »^„ •. , * . . • 

CO 7X (F (G ?X,in. MltluT^.^i ^ % y a" t T^H MHs 
(F eCa G US A e ,m 0U, H- h H Ve t0 b ? b ° Und t0 A and/ ° r C ' The -ttg , I T ' 9 
final answer TsT^r^^ '° b-C °" ^ (R B " • Hh,ch •«"-• Th * 
pnil J h t. Bame kind of substitution is done in a more limited way when 

(JSpL ES"CELT% <A be B^) t (p d, ? X^ V**^ STP " t0 ' d t0 Pr ° Ve ™*L ( ^ 

B PXI6911 h y^P ] by a ? Mng '* t0 refute tInPLIES (ELT X!B9 

<« B L>; IP X!G9)J, where X!G9 is a skolem form. It assumes CELT X!69 <A B 
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C>] and [NOT (P X!G9)1. The first subgoal becomes, via the definition of ELT, 
[OR (=/> 'X!69 A) (=/> 'X!69 B) (=/> 'X!69 C)]. When this is split, the first 
subgoal generated is [=/> 'X!G9 A]. The only effect this can have is by 
substitution, so the system finds all formulas that mention X!G9 and does the 
indicated replacements. (There won't be very many, because X!G9 is a new 
skolem form.) In this case, the subgoal [NOT (P A)] Mill be generated! 
Similar things will happen in the other two branches of this split. To make 
this work requires a bit of mechanism not usually implemented in theorem 
provers; the data-base machinery of (HcDermott, 1975) must be augmented so 
that from any pattern one can retrieve all the formulas which contain it. 
This is done by keeping track of all the positions an atom appears in, and 
intersecting the index buckets corresponding to atom positions compatible with 
the pattern. 

Modality — Complications are introduced by the use of data pools to 
implement "reference points." (Sect. II. B. 2) When the system has a goal of 
the form [T |ref| |fact|], it attempts to "coerce" the ref into a data pool. 
It then pushes this data pool as it did the calling one, and puts the fact 
into it for refutation. 

Data Dependencies — STP keeps track of the data that support its 
conclusions. Its caller will use these to build data dependencies as 
described in Sect. II, D. The only tricky part to this is to make sure the 
data pools are kept straight. Uhenever working on a [T...] expression causes 
a jump to a new pool, the supporters will be packaged up in the form (OD-T 
Ipool name| | fact | ) . These ultimately end up in this form in the 
dependencies. (See Sect. II. D.) 

Lire with Boyer and Moore — J Moore has informed me (personal 
communication) that several people have used their representation for clauses. 
(1972) For the benefit of those tempted to use it, I should report my 
experiences with it. 

My original motivation for wanting to represent formulas as closures was 
to preserve a perspicuous representation of goals for interaction with advice. 
The usual predicate-calculus theorem prover renames all the variables in two 
formulas before unifying them;, this is called "standardizing them apart." 
Boyer and Moore's motivation was to save storage by representing clauses 
incrementally, as the differences between input clauses and output claunes of 
deduct i ons. 

Neither of these reasons turned out to be important, so that this is a 
classic example of the dangers of bottom-up programming, or anticipating 
problems that never arise or are swamped by other effects. As I discussal in 
Sect. VLB, my deductive goals never interact with advice anyway: and Boyer 
and Moore's effort to save storage is wasted in a system, like mine, which 
must index each clause atom by atom. (Actually, the system is not quite that 
stupid, but I think any savings incurred are minute.) 

On the other hand, the representation has proven to have several verg 
natural uses. The packet machinery of (McDermott, 1975) "actualizes" 
potential items by just replacing the potential environment with the real one. 
The answer calculation described above is completely natural in a system that 
represents clauses by their deductive histories. The evaluation machinery 
that tries to evaluate only subexpressions with newly instantiated variables 
operates by traversing the expression to be evaluated, comparing variable 
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values in the old environment with those in the new. 

On balance, my conclusion is that these advantages do not outweigh the 
disadvantages, which are considerable. The principal one is that CAR and CDR 
are useless for operating on closures. You cannot take the first step into a 
closure without setting up its environment. Every function that manipulates 
them must treat assigned variables as though they were transparent (i.e.. go 
straight to their values); and correctly handle envid's that direct attention 
to the proper parts of the environment tree. Boyer and tloore show in their 
paper that it is easy to write a unification algorithm for closures, -indeed, 
it is easy to write any one algorithm, but the fact that every manipulation 
has to take the same tedious cases into account is something I didn't foresee. 
I solved this problem to some degree by writing a set of functions (with names 
like FMAP and FHACK) which (analogously to LISP's MAP functions) map 
operations over Boyer-Moore data structures. But these functions have to bind 
special variables and use MACLISP functional arguments, so they are of 
necessity quite slou. To get the CAR of a formula, you have to write (FHACK 
(FUNCTION CAR) FflLA) j this binds two special variables, does an uncompilable 
proper ty-M st lookup on CAR, and still returns an object (such as " (#F -CLOSURE 
(P ?X) 3)") which is meaningless without further bit-picking in the formula's 
environment tree. 

Alas, these problems are complicated an order of magnitude by interactions 
with segment forms and embedded formulas. (See Appendix 1.) Processing an 
embedded formula often requires setting up a stack of environments, which is 
pushed and popped as you go into a pair of brackets or encounter an escape 
form. 

Finally, it is very hard to develop intuitions about the structure of 
environment trees. A buggy program that manipulates envids doesn't do 
anything radically different from a correct program; it's just looking at the 
wrong parts of the environment tree. The envids it uses are just little 
.integers with Tittle meaning. Debugging such a program usually comes down to 
experimenting with different numbers until something works? 
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